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: Michael Smith <email@hidden>
- Date: Mon, 30 Oct 2006 13:00:44 -0800
On Oct 30, 2006, at 12:04 PM, Dan Shoop wrote:
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'.
It should be noted that there are two viable, separate, operations:
A - copy a file
(make a new file whose contents are the same as the original)
B - duplicate a file
(make a file that is in every way practical identical to the original)
Both of these have their place, and the Unix™ philosophy supports both.
It is worth noting that by precisely cloning a file, you may inherit
arbitrary attributes of the original of which you are unaware and
which it may not be in your interest to inherit. It is also worth
noting that there are attributes of the original that the system may
not want, or permit, you to copy. Thus for an application that
cares, operation B may be built out of a combination of operation A
and a selective transferral of attributes, or operation B followed by
a selective elimination, depending on circumstances.
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
No, it is not. It is a result of cp(1) performing operation A.
You could reasonably argue that the -p option to cp(1) implies
operation B, and that a failure to preserve the creation time
attribute is a bug in cp(1), but the conclusions you draw from your
assertion above are in error.
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.
I trust that the above elaboration will finally cause you to leave
the corpse of this departed equine well alone.
There are bugs that are worth filing, if you haven't already. But
there are also points that you need to absorb if this discourse is to
be fruitful.
= Mike
_______________________________________________
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