Description of problem: cant delete bookmark Version-Release number of selected component (if applicable): (lynx -version) Lynx Version 2.8.6rel.5 (09 May 2007) libwww-FM 2.14, SSL-MM 1.4.1, OpenSSL 0.9.8g, ncurses 5.6.20080927(wide) Built on linux-gnu Nov 10 2008 06:54:52 How reproducible: Steps to Reproduce: 1. 'v' to view bookmark 2. 'r' to delete selected bookmark 3. Actual results: " Alert!: Unable to reopen temporary file for deletion of link. Arrow keys: Up and Down to move. Right to follow a link; Left to go back. H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=h " Expected results: Additional info: it seems that development probably ceased into actually fixing this as i googled and notice that this is a persistent problem in previous versions..
Reproduced with F10 2.8.6-18.fc10
I hadn't seen this report before (so the comment about "development probably ceased" is pure speculation). Google doesn't show me any related reports, based on the message. Lynx keeps track of temporary files by their names. If something deletes a temporary file, that could confuse lynx. I don't see any other obvious way to produce this error message. Details on how to reproduce the problem would be useful.
^^ Deleting a bookmark.. I already told you how to reproduce the problem. 1. Add a bookmark using 'a'. (add a bookmark say for /etc after navigating to '/') 2. Use 'v' to view bookmarks. 3. Highlight the bookmark, and hit 'r' to delete it. Right after step 3 you should have that message. " Alert!: Unable to reopen temporary file for deletion of link. Arrow keys: Up and Down to move. Right to follow a link; Left to go back. H)elp O)ptions P)rint G)o M)ain screen Q)uit /=search [delete]=h " ^^ If u can't reproduce this error. Then try adding bookmarks using the file navigator. (meaning try adding bookmarks of '/etc' and '/' paths instead of http://) btw there's other reports of this error on google. I'm using debian's lynx(2.8.7dev.9 apr 2008) and it does not have this problem. " Lynx keeps track of temporary files by their names. If something deletes a temporary file, that could confuse lynx. " ^^ probably lynx is not making temporary files correctly on my system which would be another type of bug. This fc10 install is brand new..
Two points: a) you haven't provided enough information for me to reproduce the problem. (If it's fc10-specific, I won't anyway - don't have that). b) That's the second comment about reports on google. A url (or the search terms) would help.
"(If it's fc10-specific, I won't anyway - don't have that). " ^^ uh.. obviously you're not the one who should address this problem then. The title clearly says "FC10" .. get updated.. "Comment #1 From lexual (floss.name) 2009-02-24 01:33:39 EDT (-) [reply] ------- Reproduced with F10 2.8.6-18.fc10 " ^^ was able to reproduce the error as well. You should close this thread as nobody seems to care about this package.. and some people just don't know how to address problems. Stick with ur firefox. I'll see who wants to fix this..
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
I am able to reproduce it even with lynx-2.8.7-1.fc13. Reopening.
On the other hand, I have not encountered this. Perhaps you can describe the configuration precisely enough that I can reproduce it.
Created attachment 381962 [details] gdb trace Note it does not happen when running lynx as root. I am able to get over the bug using the following patch: --- a/src/LYUtils.c +++ b/src/LYUtils.c @@ -5849,8 +5849,8 @@ static FILE *OpenHiddenFile(const char *name, const char *mode) } else #endif if (*mode == 'a') { - if (IsOurFile(name) - && chmod(name, HIDE_CHMOD) == 0) + if (/*IsOurFile(name) + &&*/ chmod(name, HIDE_CHMOD) == 0) fp = fopen(name, mode); else if (lstat(name, &data) != 0) fp = OpenHiddenFile(name, binary ? BIN_W : TXT_W);
The IsOurFile check has been there quite a while, and removing it doesn't answer the question of what scenario and configuration we're discussing.
That's of course not what I wanted to say :-) Do you have any idea how the OpenHiddenFile() function is supposed to work? I hadn't had time to elaborate its semantic. In particular, why does it want to return a NULL pointer in my case? Have you looked at the trace from attachment #381962 [details]? Any hints are highly welcome as I am completely new to the lynx's code. I can also describe the scenario more accurate once you tell me what properties of my configuration are important to make the OpenHiddenFile() happy. Thanks in advance!
I'm the upstream maintainer (I wrote IsOurFile for instance). In lynx, temporary files are used to store working copies of webpages and downloaded files. (Lynx's source-caching can move much of the webpages into memory, but still uses temporary files for compress webpages). Temporary files are "hidden" (chmod'd to prevent reading by other users). They're also limited to being in directories where other users cannot for instance rename the file and substitute their own. The checks are possibly in some cases over/less restrictive. Perhaps you're testing in a directory which is group-writable, for instance.
(In reply to comment #13) > I'm the upstream maintainer (I wrote IsOurFile for instance). Great! Welcome at the downstream bugzilla :-) I am actually a new packager of your lynx. Feel free to ping me if any RH related lyxn's issues arise. > Temporary files are "hidden" (chmod'd to prevent > reading by other users). They're also limited to > being in directories where other users cannot for > instance rename the file and substitute their own. Among others you are checking the temporary file for S_IWGRP (not writable by group) within IsOurFile(). However your code does not seem to guarantee this permission bit to be set accordingly. > The checks are possibly in some cases over/less > restrictive. Perhaps you're testing in a directory > which is group-writable, for instance. Checks may be ok, but the surrounding code should not also be in conflict with them. I am able to avoid the the bug with: $ chmod g-w $HOME/lynx_bookmarks.html I am able to trigger the bug again with: $ chmod g+w $HOME/lynx_bookmarks.html What's the proper way to address it?
Well, for the slice we're looking at, lynx is doing both an existence-check and permissions-check. You _could_ reverse the order of the chmod/IsOurFile calls; however if it happens to be pointing to a symbolic link, then that could point to "any" of the user's files (and would be a nuisance if it were the wrong one). IsOurFile does assume that group-writable files can be written to be other users. I note that on many systems, there's the use of groups that aren't shared between users. It's easy to find the available groups, but I don't recall any automatic way to ensure that they aren't shared. Relaxing that part of the check would have to be done via a configurable setting, e.g., in lynx.cfg When I wrote that, we had some inconclusive discussion about the t-bit on directories, which amounted to not trusting that completely. (On some older systems, it is possible to set the t-bit but with a different result than protecting files). Looking at the code for IsOurFile now, I can see a couple of places where I could improve the checking - but those would make it more restrictive than it is now (a different topic).
Well, I am fine with keeping IsOurFile() as is, completely. It's not going to be called for "$HOME/lynx_bookmarks.html" either. What I am proposing is to ensure lynx sets the proper permission bits for its temporary files, so that all the checks within IsOurFile() pass afterwards. What happens now is the temporary files has the same permissions as "$HOME/lynx_bookmarks.html". If we force the file to have more restrictive permissions than the original file, IsOurFile() will be happy.
Created attachment 383388 [details] diff to make bookmark permissions compatible with IsOurFile()
Comment on attachment 383388 [details] diff to make bookmark permissions compatible with IsOurFile() Thanks! The patch looks sane and solves the problem for me. Are you going to apply the patch upstream?
Maybe a stupid question ... but where is actually placed the official upstream repository?
built as lynx-2.8.7-2.fc13
yes, I just committed it (had waited for your response). Lynx repository is two places: my home machine (where the $LynxId$ keywords are maintained) and lynx.isc.org (which uses PRCS, maintains the handful of related versions). Neither repository is web-accessible. I snapshot interim diffs from my home machine in ftp://invisible-island.net/temp (see lynx2.8.8dev.2b.patch.gz) and lynx is in http://lynx.isc.org/current At the moment I'm working on dialog, intending to fix backlog for lynx next. So this would be in 2.8.8dev.3 (I've been slow since I've had a lot of xterm and vile work recently).
lynx-2.8.6-24.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/lynx-2.8.6-24.fc12
(In reply to comment #21) > I snapshot interim diffs from my home machine in > > ftp://invisible-island.net/temp > > (see lynx2.8.8dev.2b.patch.gz) Thanks you for the info! I'll look there when checking for already fixed bugs, and eventually create patches based on the latest snapshot. But there are actually no bugs opened agains lynx in the RH bugzilla right now. We have only two RFEs - support for NSS and support for IPv6. I haven't had time to look closer at them yet.
lynx-2.8.6-24.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update lynx'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-0632
lynx-2.8.6-24.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.