Re: st_ctimespec not implemented?
Re: st_ctimespec not implemented?
- Subject: Re: st_ctimespec not implemented?
- From: Terry Lambert <email@hidden>
- Date: Thu, 26 Jun 2008 16:03:48 -0700
On Jun 26, 2008, at 3:54 PM, Chris wrote:
On 27/06/2008, at 3:51 AM, Terry Lambert wrote:
On Jun 26, 2008, at 7:02 AM, Chris <email@hidden> wrote:
On 26/06/2008, at 11:46 PM, Jean-Daniel Dupas wrote:
Le 26 juin 08 à 15:29, Chris a écrit :
I was looking for a way to figure out how long files have been
in the trash, and I was hoping that stat.st_ctimespec would
provide that, seeing as stat(2) says that rename(2) and link(2)
will update the ctime.
However this isn't the case. Renaming files doesn't affect the
ctime. Is this because Darwin doesn't implement ctime, or
because HFS+ doesn't implement it, or am I missing something else?
Or because moving a file on HFS+ is not considere as renaming
it ? On HFS+, the file name is just an other metadata (like
ctime) and is not formely part of the path.
Moving a file in HFS+ is just changing its parent, not its name.
ctime on unix has nothing really to do with the path either, but
rather the inode. Even on HFS, making another link to the file
will update the ctime. In fact that is an old fashioned way of
renaming on unix - link to the new path and unlink the old path
(which temporarily changed the inode link count). Since BSD unix,
rename is now done in the kernel rather than link/unlink, but it
is still considered an event that is supposed to update the ctime.
Incorrect; POSIX states that the st_ctime and st_mtime of the
directory that the file was renamed from/to shall be marked for
update. The file itself is unchanged by the operation; it has no
idea that it has been renamed.
Even if POSIX is silent about ctime for the file, the Mac-OSX
documentation for stat(2) is not silent, and says that the ctime
should be updated. Also, all the UNIXes that I am aware of will
update the ctime for rename.
The documentation is wrong and the specification and current
implementation is correct. Please file a bug report so that we can
update the documentation.
<http://bugreport.apple.com>
Thanks,
-- Terry
You could maybe stretch an implementation detail of HFS and claim
that the btree linkages for the catalog node have been changed, and
that therefore directory mtime has been changed, but that will
likely not fly very far.
I think its fair to say that all talk of btrees, cagalogs and other
implementation details aren't really relevant to the discussion of
what an API should do. You don't change an API just because some
implementation detail is different.
The directory ctime argument for its update on a directory change
is actually predicated on another assumption that might not be
valid, based on the implementation detail that "directories are
files, and changing directory data is therefore changing file
contents". This was true for UFS, but is not true on btree-based
directories in HFS or other FSs with different implementation
details. POSIX should probably update the standard to only mtime
being "shall be marked for update", and ctime "may be marked for
update", but it's not costing us more than a flag compare and an
assignment to do both.
I don't see that the cost is the primary consideration in
formulating standards. All the meta-data imposes cost, but we have
it because it is useful. In this case, ctime is remarkably
irrelevant if rename doesn't update it.
_______________________________________________
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
_______________________________________________
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