site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com

...

<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".

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. 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. Specifically, he's asking for: cp->c_touch_modtime = TRUE; <http://www.opengroup.org/openbrand/register/brand3555.htm> See also the Single UNIX Specification: -- Terry _______________________________________________ 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 Jul 9, 2007, at 6:03 PM, Mike Frysinger wrote: 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. It does; the metadata (file length) was not changed, but the file was opened for write. No metadata change, no mtime change. 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. prior to the call to hfs_update at the end of the function do_hfs_truncate() in bsd/hfs/hfs_readwrite.c; that just sets a flag. The actual time isn't really updated until some time later. So the time stamp that gets put on the file would depend on when an updating operation too place subsequent to the flag getting set (it being marked for update). 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 <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. 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. This email sent to site_archiver@lists.apple.com