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 13:00:02 -0700
On Aug 9, 2006, at 5:50 PM, Dan Shoop wrote:
At 12:42 PM -0700 8/9/06, Terry Lambert wrote:
On Aug 7, 2006, at 2:01 PM, Jeffrey Ellis wrote:
Hi--
If the Finder is based on Darwin, why are there no direct commands
which will replicate a Finder Copy, i.e., copy all the metadata
for a given file, not just it's resource forks as in ditto or rsync?
I guess basically, the question from a programming standpoint, is
there a way to replicate a Finder Copy without actually calling
the UI?
Sorry for the n00b-ness of this question.
Thanks :)
"man cp".
The short answer is that the command line utility "cp" will copy
the metadata by default unless you tell it not to by specifying "-
X" as one of the arguments. So the support is already there, and
on by default.
If the metadata in question includes ACLs, then you will want to
specify "-p" to "preserve attributes" - primarily, protections and
timestamps - of which ACLs are a subset.
cp does not duplicate the behavior of the Finder, nor does ditto.
There are two copy engines; one is the Finder's, which is built on CF,
and the other is for lack of a better name, called "the POSIX copy
engine". We wanted there to be a single copy engine, but the Finder
had requirements because of GUI objects that caused it to need to do
things in parallel.
For the most part, for command line tools, we actually don't *want*
the Finder copy behaviour, since because it uses pre-caching to do the
copy, it will end up with com.apple.system.Security extended
attributes on it, even if it didn't have them before. This is mostly
harmless, but it would have the effect of making something Mac-like
when it wasn't previously, which might not be desirable in a command-
line (UNIX) environment.
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"
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 - 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.
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).
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: it depends on whether the
person who wrote the POSIX copy engine shares my philosophy on things,
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..
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.
-- Terry
:Shameless Plug:
See this month's issue of MacTech for a further analysis and
discussion. I believe there are copies available at the WWDC, if
you're there.
See http://iwiring.net:8000/papers/Who_Copies_What.pdf for a summary
of how tools compare, from this article.
If you're interested in a copy of the article, email me privately.
At 4:16 PM -0700 8/9/06, Jeffrey Ellis wrote:
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.
Because ditto and cp copy different metadata. For instance ditto
doesn't copy BSD flags while cp can. (The Finder only copies one BSD
flag, uchg)
Bottom line if you want the behavior of the Finder you need to use
the Finder. Neither ditto, cp, tar, rsync or other tools handle
metadata in the exact same manner.
--
-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