From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51207) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZu3k-0000S8-5Q for qemu-devel@nongnu.org; Tue, 07 May 2013 22:24:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UZu3i-0007RL-WB for qemu-devel@nongnu.org; Tue, 07 May 2013 22:24:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UZu3i-0007RF-OU for qemu-devel@nongnu.org; Tue, 07 May 2013 22:24:46 -0400 Message-ID: <5189B76B.50509@redhat.com> Date: Tue, 07 May 2013 20:24:43 -0600 From: Eric Blake MIME-Version: 1.0 References: <518923DA.6030105@redhat.com> <1367945808-19979-2-git-send-email-lersek@redhat.com> <51893A22.1040105@redhat.com> <51899DDC.3060101@redhat.com> In-Reply-To: <51899DDC.3060101@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="----enig2SJIVXIJSRQVHOLLATWXS" Subject: Re: [Qemu-devel] [PATCH 2/2] qga: try to unlink just created guest-file if fchmod() fails on it List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2SJIVXIJSRQVHOLLATWXS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/07/2013 06:35 PM, Laszlo Ersek wrote: >> This fixes the case of a mode 0000 file if fchmod fails, but doesn't f= ix >> the case of a mode 0666 file if fchmod succeeds but fdopen fails. It >> also requires that unlink() while open works (true for most Unix >> systems, but false for Windows systems and not required by POSIX >=20 > Please provide a reference for "not required by POSIX". The EBUSY > condition I'm looking at says "The file named by the path argument > cannot be unlinked because it is being used by the system or another > process and the implementation considers this an error". That's precisely what I'm looking at. The Windows implementation considers any open file as in use by the system, and gives an error when trying to unlink an open file (it also gives an error when trying to rmdir a directory that serves as the current working directory of any process). Another case is NFS, which has historically had not-so-nice behavior if you attempt to unlink an open file (such as the file still being resident in cache for several seconds longer and preventing removal of a directory), whereas closing first and then unlinking suffers from no delay or weird caching effects (admittedly, NFS as a file system breaks several POSIX rules). You are right that POSIX unlink() also says "If one or more processes have the file open when the last link is removed, the link shall be removed before unlink() returns, but the removal of the file contents shall be postponed until all references to the file are closed." But I read that as permitting (but not requiring) an implementation to unlink an open fd, if it further follows the rules about the file contents when unlinking an open file. Meanwhile, the EBUSY error permits (but not requires) implementations to let unlink fail on an open file, and NFS serves as a case study of this behavior even on Unix-y systems. Even if you don't buy my argument about EBUSY, and even though we both agree that Unix-y systems have historically allowed unlink of an open file on a local file system (as well as rmdir of the current working directory), it still doesn't change the fact that in reality, such actions are not portable to Windows or NFS. And whether or not Windows is non-compliant with POSIX doesn't matter quite as much as whether our code is portable to the systems we are porting to. >=20 > "Used by the system or another process" shouldn't really be the case he= re. Used by another process - no. Used by the system - yes, if the system considers all open files to be in use. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org ------enig2SJIVXIJSRQVHOLLATWXS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJRibdrAAoJEKeha0olJ0Nq0RsIAJS0JsAEWAKxbyihv2mx2BL8 nQ7StvEBsD/8V8AtwVe4UO9d9C6HmMaJaoko2+cl24FGVa5ShtiFTLJAQ9hn6s3a TCdlW7eoQXNESrNjScQzwXDz4JasCX4j5y1TjyiwtZPbC/14WI0KzTltbBWeNHPp ekknTENWPm6MiC7nivUn4yK3rwrNvJ+VFV7Zkvo4aU8EB8TrYremIakdXYZPjYzE k9qziEiikQqZ4LT7pdas6COUAeHHLUUVH+0mTN/L0P6UOMvanxK9uTsDGFs2m+Pi AUwjaOeA90/wrRxKRv2QfMGaYZTSko/pcVG+dWbHJct6mejjFAaaYGgvyfvfzFg= =DhIM -----END PGP SIGNATURE----- ------enig2SJIVXIJSRQVHOLLATWXS--