+++ This bug was initially created as a clone of Bug #486070 +++ --- Additional comment from kdudka on 2010-01-06 12:41:42 CET --- 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); --- Additional comment from dickey on 2010-01-13 02:37:44 CET --- Created attachment 383388 [details] diff to make bookmark permissions compatible with IsOurFile()
Thomas, while analyzing the patches inside lynx-2.8.7-6.fc15, I discovered something odd in the patch above. Could you please have a look at the following code? mode = ((stat_buf.st_mode & HIDE_CHMOD) | 0600); /* make it writable */ ... means the same as: mode = 0600; That is, the value of 'mode is' independent of stat_buf.st_mode. Is that intended?
yes - it's redundant to "OR" HIDE_CHMOD (which is 0600) and the actual 0600, but if HIDE_CHMOD were more lax, e.g., 0640, then the result could inherit a read-bit from stat_buf.st_mode So (aside from a qualm about the redundancy), it seems to be doing what I intended, which was to use HIDE_CHMOD to select only the bits that correspond to a "hidden" file, and then to add back the bits that let lynx read/write the file. I'd have used symbols from <sys/stat.h>, however those (especially when I wrote that 10-12 years ago) have portability issues.
Thanks for clarifying that. So the construction makes sense in case you changed the definition of HIDE_CHMOD in <LYUtils.h> to something else in the future. Then we can probably close the bug.