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 20:44:49 -0400
At 1:00 PM -0700 8/10/06, Terry Lambert wrote:
There are no shell commands I'm aware of that accurately duplicates
its behavior. (Which is a huge shame.)
There's always:
osascript -e "some AppleScript command to cause the Finder to
do the copy"
I'll have to remember that one, thanks.
One telling issue is that the Finder properly preserves Creation
Date, while command line tools do not.
POSIX stores the atime, mtime, and ctime - access time, modification
time, and change time.
I'm not sure where I stand on the "creation date" (which could be
preserved by copy if it used getattrlist() and setattrlist()) to try
and preserve it. On one hand, the creation date is the time that
the file was created - which is when you did the copy
That's ctime, not Mac "creation date."
$ stat file
234881027 3063481 -rw-r--r-- 1 dshoop dshoop 0 0 "Aug 10 13:48:51
2006" "Aug 10 13:48:51 2006" "Aug 10 13:48:51 2006" 4096 0 0 file
$ /Developer/Tools/GetFileInfo file
file: "/Volumes/OoblekData/dshoop/xyzzy/file"
type: ""
creator: ""
attributes: avbstclinmedz
created: 08/10/2006 13:44:10
modified: 08/10/2006 13:48:51
On the Mac "creation date" has always been promoted as the original
date on which the file was created. That is copies of files have
always maintained it and Mac users expect it and use it for sorting
of files and tracking of the actual time a file was originally
created.
- and not the time that the original was created. On the other
hand, if the intent of the copy was to create an identical copy,
then you'd need to copy the creation date as well.
As I point out in my article there are philosophical aspects to what
metadata should be maintained depending on what "copy" means to you.
This is understandable.
However the behavior on the Mac of creation date has been rather well
codified and further re-enforced through precedent along with how
un-Mac-like environments should maintain things like creation date
using techniques like Apple Doubles where necessary.
OS X's BSD environment improperly creates Apple Doubles (making them
in fact not true Apple Double representations of the original file)
as it munges the modified date into the creation date field in
opposition to the specs that Apple Double defines should be the
behavior.
My personal take on this is that setting dates on files should
require ownership of them, and setting creation dates on files is
(effectively) asking the system to lie to the next person who looks
at the file (the POSIX utime() system call doesn't actually
understand the concept of "create time" separate from the other
times, since it only understand 3 timestamps at the API level; in
HFS terms, that's ca_atime, ca_mtime, and ca_ctime, and neither of
ca_itime or ca_btime).
This is an interesting approach, requiring ownership to set dates.
However this falls apart for several reasons:
(1) Creation Date is not ctime so it's apples[sic] and oranges. So
it's not lying at all as it can change ctime and not affect creation
date and stays completely consistent.
(2) The Finder doesn't respect BSD ownerships anyway when making copies.
(3) It ignores the traditional behavior that Mac users have come to expect
(4) The philosophies are in fact not at odds at all they can coexist
since ctime and creation date are distinct
The BSD behavior for creation dates is to munge it with modified
date, even when creating what are arguably not Apple Doubles (since
the Apple Double spec says that this metadata should be preserved
in the Apple Double) either explicitly based on their necessity due
to foreign file systems or even 'internally' when copying to HFS
based volumes.
FWIW, this may or may not be on purpose
I'd suggest its from a failure to understand the differences of ctime
and creation date coupled with the nature of how unix treats ctime,
further coupled with a failure to understand the heavy reliance that
Mac users traditionally place on this metadatum.
it depends on whether the person who wrote the POSIX copy engine
shares my philosophy on things,
Your philosophy is interesting, but I don't see how it applies here.
Moreover this isn't a btime issue either.
or if the utime() system call update occurs after the setattrlist()
and carries things along with it, or if updating the creation time
outside of an actual create operation by the FS is considered
privileged - i.e. you have to be "root" to be permitted to cause the
system to lie to the user - or some other reason I haven't thought
of, etc..
Clearly the Finder has no issues maintaining this in userspace. Why
would it be any less possible for BSD?
You could always file a bug on this, asking for a tech note for
clarification of the philosophy, or a fix, if it's actually a bug.
I believe there already is one open, #4506951 (suggested by
http://blog.plasticsfuture.org/2006/06/27/mac-os-file-creation-dates/)
. However I've found that Apple has a very poor track record
(compared to to vendors) with respect to reported bugs.
--
-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