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 > 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... /usr/bin/perl5.12.4 and /usr/bin/perl are hardlinks to the same file. In the tar archive, the former is a real file and the latter is marked as hardlink. The race condition happens because hardlinks do not use deferred renames so /usr/bin/perl is put into place with the content of /usr/bin/perl5.12.4.dpkg-new which has not yet been fsync()ed and renamed. If a perl script is started before the deferred fsync/rename, the open with write rights on /usr/bin/perl5.12.4.dpkg-new will fail. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
