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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OScnyEwIbMoZkV48eKXQPegspUROi8JRZK3ZCR9q5sfJjBn2xqm1klRe7RDhfSXP03gEmwgViP0GA8CuBTXTqL1XLPc7OoWJ0kjsoXUzNT0/nfJbe4DqSCOG1pnJf57v1fpzDCn3f8cLey3K1DJ3zD8LB/fab1Tjeia8iJww2lI= Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SX+FNHC2yP31gVcvt0Xb8m0VwCbYEELmTAluhSvXBh/7Ca4XS6H9Oim3QyVRHSJrZ3U1P6yXBY0TTi9xMNSXtPu7gHx98yy/LRcM/LUIqUXb4SebTrZEKZLKdkSOtIEhQpDQ6jNYGY4Z7tXTPLjTJTRaWqLg6Us2VWK6+11IrYU= On Jul 9, 2007, at 12:09 PM, Mike Frysinger wrote:

On 7/9/07, Shawn Erickson <shawnce@gmail.com> wrote:

...

On 7/9/07, Mike Frysinger <vapier.adi@gmail.com> wrote:

...

On 6/12/07, Mike Frysinger <vapier.adi@gmail.com> wrote:

...

i was tracking down a bug in the Linux kernel build system which seems to be caused by a bug in Darwin. the kernel build system creates a bunch of 0 byte files and then uses open(O_TRUNC) on them in order to update the st_mtime field (which triggers make to recreate some object files). on my mac mini, this all falls apart.

is there somewhere i can file a bug report about this ? i'm really not familiar with Darwin development methodologies

<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 It's perfectly legitimate under POSIX to check the length of the file before attempting the truncation, and if the truncation would have no effect, not call into the VOP to do the truncation, thus not modifying the file. 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. 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 See also the Single UNIX Specification: that is the spec ive been quoting all along -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: <http://www.opengroup.org/onlinepubs/009695399/functions/open.html> This email sent to site_archiver@lists.apple.com