Re: First timer: Finder Copy vs. cp
Re: First timer: Finder Copy vs. cp
- Subject: Re: First timer: Finder Copy vs. cp
- From: Dan Shoop <email@hidden>
- Date: Thu, 10 Aug 2006 22:19:30 -0400
At 3:50 PM -0700 8/10/06, Terry Lambert wrote:
On Aug 10, 2006, at 3:20 PM, Dan Shoop wrote:
At 1:03 PM -0700 8/10/06, Terry Lambert wrote:
On Aug 9, 2006, at 4:16 PM, Jeffrey Ellis wrote:
Hi, Terry--
Wow... I saw a list of everything cp does, and you're right. It looks like
it does everything.
Okay, so I guess this is my next question. If cp does everything, why would
anyone use ditto? I always thought that was used because of it's ability to
copy resource forks.
Personally, I don't use ditto... I expect it's a matter of
personal preference, and what you're used to using.
Ideally it should be a matter of choosing the tool (or combination
of tools) that copy the metadata you're interested in rather than
choosing one or another for religious reasons and just
hoping/assuming it copies what you need.
Unfortunatley there seems to be a lack of understanding by users,
sysadmins and even Apple engineering as to what tools copy what
metatdata. And then there's the philosophical issue as to what each
tool /should/ be copying. While it's understandable, from a
philosophical standpoint, that if you copy a file it might be
considered a new entity and shouldn't maintain, say ACLs, creation
dates, Finder Attributes and other metadata are arguably expected
by most Mac users.
I like one tool, with option flags; encoding the options in the name
of the tool (;^)) doesn't work for me.
One tool would be nice, yes.
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. ;)
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.
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.
ctime, being change time, is effected even by a chmod.
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:
Creation date is createDate.
ctime appears to be attributeModDate
$ sudo /Volumes/OoblekData/LocalApps/singh/hfsdebug file
Password:
path = OoblekData:/dshoop/xyzzy/file
# Catalog File Record
type = file
file ID = 3065440
flags = 0000000000000010
. File has a thread record in the catalog.
reserved1 = 0
createDate = Thu Aug 10 21:51:35 2006
contentModDate = Thu Aug 10 22:10:14 2006
attributeModDate = Thu Aug 10 22:10:14 2006
accessDate = Thu Aug 10 22:10:14 2006
backupDate = Fri Jan 1 00:00:00 1904
# BSD Info
ownerID = 501 (dshoop)
groupID = 501 (dshoop)
adminFlags = 00000000
ownerFlags = 00000000
fileMode = -rw-r--r--
linkCount = 0
textEncoding = 0
attrBlocks = 0
# Finder Info
fdType = 0
fdCreator = 0
fdFlags = 0000000000000000
fdLocation = (v = 0, h = 0)
opaque = 0
# Data Fork
logicalSize = 0 bytes
# Resource Fork
logicalSize = 0 bytes
22:10:45 dshoop@ooblek:~/xyzzy
$ chmod u=rwx file
$ sudo /Volumes/OoblekData/LocalApps/singh/hfsdebug file
path = OoblekData:/dshoop/xyzzy/file
# Catalog File Record
type = file
file ID = 3065440
flags = 0000000000000010
. File has a thread record in the catalog.
reserved1 = 0
createDate = Thu Aug 10 21:51:35 2006
contentModDate = Thu Aug 10 22:10:14 2006
attributeModDate = Thu Aug 10 22:11:58 2006
accessDate = Thu Aug 10 22:10:14 2006
backupDate = Fri Jan 1 00:00:00 1904
# BSD Info
ownerID = 501 (dshoop)
groupID = 501 (dshoop)
adminFlags = 00000000
ownerFlags = 00000000
fileMode = -rwxr--r--
linkCount = 0
textEncoding = 0
attrBlocks = 0
# Finder Info
fdType = 0
fdCreator = 0
fdFlags = 0000000000000000
fdLocation = (v = 0, h = 0)
opaque = 0
# Data Fork
logicalSize = 0 bytes
# Resource Fork
logicalSize = 0 bytes
22:12:00 dshoop@ooblek:~/xyzzy
ttyp1$
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 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.
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.
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.
ctime, and even btime are, agreeably, of dubious value on unix
systems, but the Mac's "creation date" is a very different beast and
should be a different matter. Moreover the Finder's behavior *does*
maintain "creation date" consistently and w/o any privileges.
--
-dhan
------------------------------------------------------------------------
Dan Shoop AIM: iWiring
Systems & Networks Architect http://www.ustsvs.com/
email@hidden http://www.iwiring.net/
1-714-363-1174
pgp key fingerprint: FAC0 9434 B5A5 24A8 D0AF 12B1 7840 3BE7 3736 DE0B
iWiring provides systems and networks support for Mac OS X, unix, and
Open Source application technologies at affordable rates.
_______________________________________________
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