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: Terry Lambert <email@hidden>
- Date: Mon, 9 Jul 2007 21:15:50 -0700
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.
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.
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.
Specifically, he's asking for:
cp->c_touch_modtime = TRUE;
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/openbrand/register/brand3555.htm>
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.
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.
-- Terry
_______________________________________________
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