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 10:51:01 -0700
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.
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.
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.
-- 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