Re: First timer: Finder Copy vs. cp
Re: First timer: Finder Copy vs. cp
- Subject: Re: First timer: Finder Copy vs. cp
- From: Terry Lambert <email@hidden>
- Date: Thu, 10 Aug 2006 20:56:16 -0700
On Aug 10, 2006, at 7:19 PM, Dan Shoop wrote:
This is the first time I've heard anything about someone wanting
the create time copied;
:incredulous look:
I'll guess ahead of time that you're a unix-head w/o prior exposure
to MacOS or many other OSen that possess creation dates. ;)
On the contrary; I'm a UNIX-head, yes, in that I did much of the
kernel work for the POSIX API conformance in Mac OS X, wrote the
patchkit for 386BSD that ended up becoming NetBSD and FreeBSD, and
worked for Novell USG (the former USL) on, among other things,
filesystems, in the way back.
But a chunk of time before that, I was a VMS guy and a mainframe guy,
and both those OSs had creation dates for their FS objects. And each
and every object's creation date was the creation date of the FS
object, not the contents of the object; if you needed a creation time
for the contents of the object, as part of the ISAM data in it, you
would define a field and put that information in it.
The bonus to having this as file data rather than file metadata, of
course, is that some OS programmer couldn't come along later and
change it on you, unless they understood your file contents
layout... ;^).
This behavior and response seems to be quite common amongst
engineers coming from *nix only backgrounds b/c *nix has no such
attributes. But the Mac, and many other OSen, has had it since day
one and Mac users routinely rely on this information.
I know I'm going to kick myself for asking, but... for what?
On mainframes and VMS, we cared about it because it told the backup
software which files to back up. For NetWare (which I also worked
on), it existed to tell software what files to back up. Same for FAT/
FAT-16/FAT32/VFAT32/NTFS in the Microsoft world.
to me, it's always been not useful for anything,
Becasue it has no use in *nix b/c there is no creation date, just
ctime and btime, neither of which is analogous.
Actually UNIX has:
st_atime time of last access
st_mtime time of last data modification
st_ctime time of last status change (metadata modification)
HFS has:
ca_atime time of last access
ca_mtime time of last data modification
ca_ctime time of last status change (metadata modification)
plus:
ca_atimeondisk time of last access on disk
ca_itime time of file initialization
ca_btime time of last backup
...and if you look in xnu/bsd/hfs/hfs_vnops.c in the function
hfs_vnop_setattr(), you'll see a comment to the effect of:
/*
* The utimes system call can reset the
modification
* time but it doesn't know about HFS create
times.
* So we need to ensure that the creation
time is
* always at least as old as the modification
time.
*/
which is consistent with the order of operation theory I put
forward... the only other places it gets set are higher up in
hfs_vnop_setattr(), but *ONLY* if the modification time on the file is
*NOT* being set. The only other place it deals with it is in
hfs_makenode() in the same file, where it sets everything to the mtime.
BTW, this code has been this way since Tiger, and it looks like finder
copy separately updates mtime first to avoid the itime being changed.
ctime, being change time, is effected even by a chmod.
Sure... it's supposed to be, according to POSIX IEEE standard 1003.1:
<http://www.opengroup.org/onlinepubs/009695399/functions/chmod.html>
...
"Upon successful completion, chmod() shall mark for update the
st_ctime field of the file."
but I have to admit, I tend to come at it from the direction of
POSIX, and since utime() and stat() don't have it unless it's
mapped to one of the stat fields by something that the FS has, and
the FS doesn't natively support (create time vs. metadata update
time on MSDOSFS, for instance), it's never bothered me to not have
it preserved.
AFAIK the filesystem *does* have it:
Sure. And as far as the POSIX APIs are concerned, it fdoesn't matter
because ALL file systems don't have it. POSIX is an intentional
subset, so that code written to the POSIX API will run anywhere - not
just vs. FS's that happen to implement an initialization time (it's
actually incorrect to call it "create time").
Like I said before: if it's a legitimate bug, it should be fixed;
if it's not done because you should have to be root to get the FS
to lie to the user (a create time is NOT like any other time that
you could set), it's not a bug.
The Finder does this routinely w/o being root.
Should I then consider that Apple then sees this a bug since a user
does not need to be root to copy this in the Finder by any user?
I'm pretty much saying "Maybe". It's possible that permitting the
Finder to set the create time without requiring privilege should be
disallowed.
I didn't get specific because I'm unwilling right now to do the
work to test whether it's preserved if the command line cp is done
by root instead of an ordinary user (too busy getting things
together for my talk on DTrace tommorrow morning).
It's doesn't. cp (and anything in BSD) appears to be completely
ignorant to creation date altogether as BSD itself has no equivalent
concept of creation dates. However that doesn't mean that under HFS,
a filesystem that does have the concept, it shouldn't respect it
accordingly. After all, filesystems that don't support HFS
attributes fall back to Apple Doubles which does (or should)
maintain creation date in the Apple Double.
The HFS implementation (you can look at the source code at < http://www.macosforge.com/>)
since Tiger has specifically reset the creation date on an mtimes
update. This has nothing to do with BSD, and everything to do with
the gymnastics someone was willing to go through to set the create
date separately from the other timestamps.
In other words, when the Finder sets the mtime, it sets the itime, and
then it explicitly goes back and sets the itime using a separate
system call to do so.
You may want to read http://blog.plasticsfuture.org/2006/06/27/mac-os-file-creation-dates/
first and see Jordan's responses on this list already on this.
I've read it... BTW, this is the kernel list, not the dev list - so I
didn't see that other discussion: you're posting to a different list.
ctime, under unix, is the *change time* of the file, not its
creation time. Creation Date is a concept /different/ from ctime
(and even btime), and used by MacOS and certain other non-unix OSen
that carry a concept of when a file was initially created, not when
it was changed or the inodes (or equivalent) assigned.
And it's updating the mtime from UNIX that's changing the value stored
in itime:
http://cvs.opendarwin.org/cgi-bin/cvsweb.cgi/~checkout~/src/xnu/bsd/
hfs/hfs_vnops.c?rev=1.1.1.4&content-type=text/plain&only_with_tag=MAIN
...and whether or not this constitutes a bug has yet to be determined.
Feel free to file another bug and weigh in on the matter with the
person who owns copyfile().
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden