Re: open() fails to update st_mtime when used with O_TRUNC and 0 byte files
Re: open() fails to update st_mtime when used with O_TRUNC and 0 byte files
- Subject: Re: open() fails to update st_mtime when used with O_TRUNC and 0 byte files
- From: "Mike Frysinger" <email@hidden>
- Date: Mon, 9 Jul 2007 20:09:55 -0500
On 7/9/07, Terry Lambert <email@hidden> wrote:
On Jul 9, 2007, at 12:09 PM, Mike Frysinger wrote:
> On 7/9/07, Shawn Erickson <email@hidden> wrote:
>> On 7/9/07, Mike Frysinger <email@hidden> wrote:
>> > On 6/12/07, Mike Frysinger <email@hidden> 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:
<http://www.opengroup.org/onlinepubs/009695399/functions/open.html>
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden