site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Md/BESZnSVLEjSuH61u6qROAle7hptHLfAkVkWCmbyFOZ5uZ0PIXlfr0F3TqPWZzfv6VRvEygQKUgEQqCxo4IOPW4XK2yaTS2W0AS3DoNZ/R7t3JY6f2cOseFoi7+qG+G08gFOu/SvB0UdEQ5CfhbnTZQzpVpH/tw7knKwiLscc= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SqoxTqICh+UqnUgpGq486ndnW4xzSRoM/BZFuEUnwGWkw2s+qPIBPYAkZq4muh9IYQNN8oGxfHdaQB7r9r7vLanikUNAaHb4uicjNkIBnuTpIfkLQJPi7n4Ny2eysp4x94IegAVhekZDOQiNsi5pohpfSaatMnVP0pW6rawDNlc= On Jul 9, 2007, at 6:03 PM, Mike Frysinger wrote:

...

...

...

<http://developer.apple.com/bugreporter/>

thanks, ive posted it there as #5322203

There's already a bug filed on this, and it's currently "Not to be fixed".

can you post the URI to said report please Not really; it wouldn't be visible externally anyway. It's specific to an explicit call to ftruncate(), but it's the same root cause in both instances.

i keep forgetting apple's definition of "open" != "open"

...

Specifically, the modification time will only be changed if the file is modified, which it is not, in this case (the POSIX mandate in the case of an actual truncation -- "successful completion" -- is "shall mark for update", rather than "shall update", in any event, so any code with this assumption built into it is inherently racy).

the backend details of how truncation is handled is irrelevant to POSIX so long as the behavior dictated is maintained.

"successful completion" is not defined as "file was actually truncated" but rather "open() returned a valid file descriptor (and not an error)". even if this is how POSIX described it, the behavior of updating *ctime* and not *mtime* doesnt make any real logical sense. It does; the metadata (file length) was not changed, but the file was opened for write. No metadata change, no mtime change.

again, the backend details are irrelevant ... POSIX states: If O_TRUNC is set and the file did previously exist, upon successful completion, open() shall mark for update the st_ctime and st_mtime fields of the file. * the file previously existed * the call to open() returned a valid file descriptor ("successful completion") * the spec makes no concession like "if the file is 0 bytes already, you may skip st_mtime updates"

as for the race condition, if you want to interpret "mark for update" to mean the times get updated on the fd but the file itself is delayed for updates, then simply changing to fstat() rather than stat() would address that concern. Actually, no it would not. Being marked for update is not the same thing as actually having stat information updated. What happens is that you flag the vnode to indicate that the time in the inode/cnode should be set opportunistically. There can be significant latency between setting the "update my ctime" flag, and the ctime actually being updated.

again, my view is from POSIX and nothing else. backend details (libc/kernel/whatever) have no bearing on the discussion. I don't really agree with you interpretation of the standard, though, and neither do The Open Group POSIX conformance test suites, since they don't test for this behaviour.

...

The assumptions in the Linux kernel build code are wrong; it should be using "touch", not "open with O_TRUNC".

the assumption in the kernel build code is that the system is POSIX compliant

basic logic failure: a test case merely proves that everything tested for passes, not that everything possible passes

...

See also the Single UNIX Specification:

<http://www.opengroup.org/onlinepubs/009695399/functions/open.html

...

that is the spec ive been quoting all along

Maybe you could get them to add it as a test case for the test suite, if they (specifically, The Austin Group, actually) agreed with your interpretation of the standard. i'll start a thread there It'd be trivial to call futimes(fd, NULL); after opening the fd, to not depend on the mtime/O_TRUNC interaction assumprion. As a workaround to actually fixing the assumption about mtime in the Linux kernel build system, you could either make the change described above in your own Darwin kernel sources and build yourself a new kernel, or you could use UFS instead of HFS (the easiest way would be to use it in a disk image, to avoid reformatting), since UFS acts this way. my intentions here are not for myself ... i rarely use OS X let alone ever dig into the Darwin kernel or libc nor do i ever plan on doing such a thing -mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On 7/9/07, Terry Lambert <tlambert@apple.com> wrote: <snip> <http://www.opengroup.org/openbrand/register/brand3555.htm> This email sent to site_archiver@lists.apple.com