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: Tue, 10 Jul 2007 00:02:10 -0500
On 7/9/07, Terry Lambert <email@hidden> wrote:
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.
<snip>
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
<http://www.opengroup.org/openbrand/register/brand3555.htm>
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 (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden