site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com thanks, ive posted it there as #5322203 -mike See also the Single UNIX Specification: <http://www.opengroup.org/onlinepubs/009695399/functions/open.html> -- 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 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/>

There's already a bug filed on this, and it's currently "Not to be fixed". 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 assumptions in the Linux kernel build code are wrong; it should be using "touch", not "open with O_TRUNC". This email sent to site_archiver@lists.apple.com