On Fri, 2011-08-12 at 21:10:20 +0200, Raphael Hertzog wrote: > On Fri, 12 Aug 2011, Guillem Jover wrote: > > This is misleading on Linux, but it's not a safe portable assumption > > to make on POSIX in general as that behaviour is not specified and as > > such is implementation specific, some Unix systems do actually fail > > on read-only file descriptors, for example: > > > > > > <http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V50_HTML/MAN/MAN2/0033____.HTM> > > > > <http://publib.boulder.ibm.com/infocenter/aix/v6r1/index.jsp?topic=/com.ibm.aix.basetechref/doc/basetrf1/fsync.htm> > > Bummer, there was nothing like this mentioned in > http://pubs.opengroup.org/onlinepubs/009695399/functions/fsync.html
Well POSIX is not the be all and end all of portability, not even documentation wise, although it might help when trying to set a base-line of common functionality. In any case, the open(filename, O_WRONLY) for the deferred fsync() code was done on purpose, precisely for portability reasons. > > The correct portable way to fix this would be to defer the rename of > > the symlink to avoid the usage of the actual executable which is still > > deferred, but this is a quick analysis of the situation, I've not > > actually checked the logs in depth or reviewed the case... > > Nope, there's no symlink involved and symlinks are already defferred as > well (and are safe since they are at the end of the file list). It's > a case of a hardlink... Right, I meant hardlink here, which is what Niko was talking about in the bug report, and the the code is not doing deferred renames yet. regards, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
