Re: cp creates directory with different permissions -- then reverts them
Re: cp creates directory with different permissions -- then reverts them
- Subject: Re: cp creates directory with different permissions -- then reverts them
- From: Dan Shoop <email@hidden>
- Date: Mon, 30 Oct 2006 15:04:11 -0500
At 9:38 AM +0100 10/30/06, Quinn wrote:
At 23:06 -0800 29/10/06, Jeffrey Ellis wrote:
Can someone tell me why cp is doing this?
It's the UNIX way (-:
Historically, Mac OS and UNIX had a very different perspectives on
file copying. UNIX considers the copy to be a new file that just
happens to have the same content as the original.
It should be noted that the parlance used by the Macintosh is that it
duplicates a file. This implies that that the file is a duplicate of
the original, rather than a 'new copy'.
Mac OS tries to make the new file as close as possible to the
original. This affects other things beyond the permissions. For
example, if you copy a file on traditional Mac OS (or using
technologies that conform to traditional Mac OS semantics, like the
Finder), the new file has the same creation and modification date as
the original. If you do this using "cp", the new file's creation
and modification dates are set to the time that you did the copy.
Which is caused by confusing the Mac Creation Date of a file with the
unix ctime, which (contrary to much misinformation) is not the
creation time of the file at all but the change time of the file,
something best associated with the Mac concept of Modification Date.
Unix doesn't have a concept of creation time. Why the Apple BSD
engineers have then also chosen to clobber Creation Date as well
properly updating the Modification time of a file just b/c they think
the Mac's concept of Creation Date is a gross error in a 20+ year
design seems misguided since normally when two systems have unrelated
properties between them the information is normally either preserved
or
Indeed this preserving behavior for such foreign systems -- and the
preservation of Creation Date -- was long ago codified as part of
AppleDoubles. Yet here the behavior in the "unix" side of Mac OS
clearly does not follow what should be the documented behavior and
the Apple Double "Creation Date" property is once again clobbered by
mtime, creating a bad AppleDouble.
There are many arguments as which of this approaches is 'correct',
but they are mostly pointless IMHO. Both approaches have their pros
and cons.
Regardless of which method you consider to be correct, since the two
properties are not related the unrelated property of the other method
should not be invalidated, munged or clobbered -- yet it is. This
flies in the axiom of "cause no harm" when dealing with foreign
properties.
Normally when two different systems have properties common to each
and other properties unique to each the system w/o the unique
properties defers to the other system or ignores the property of the
other rather than destroying or invalidating the non-orthogonal
property. Why the choice was made to trample on the unique property
of the other system in this case seems misguided and unnecessary.
Fortunately, Mac OS X bypasses these arguments by providing you
with tools to do both. "cp" gives you the traditional UNIX
semantics.
At the expense of clobbering a perfectly valid and different property
of the Mac semantics.
"ditto" gives you the traditional Mac OS semantics.
Actually, ditto does not preserve exactly the same set of metadata as
the Finder. Ditto does not preserve ACLs where both copying
(option-drag to a new location) and the "Duplicate" feature of the
Finder will.
In fact there is no command line tool that duplicates the
functionality of the Finder in this regard.
I'd love to discuss this off-list with Apple Engineering.
--
-dhan
------------------------------------------------------------------------
Dan Shoop AIM: iWiring
Systems & Networks Architect http://www.ustsvs.com/
email@hidden http://www.iwiring.net/
1-714-363-1174
"The wise man doesn't give the right answers, he poses the right
questions." -- Claude Levi-Strauss
------------------------------------------------------------------------
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