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: Mon, 14 Aug 2006 15:52:05 -0400
At 3:11 AM -0700 8/12/06, Michael Smith wrote:
On Aug 11, 2006, at 12:56 PM, Peter Bierman wrote:
At 2:36 AM -0700 8/11/06, Michael Smith wrote:
In particular, note that this is a new file; it is semantically
incorrect (regardless of your expectations otherwise) to mis-label
the file as having been instantiated at any time other than when
it was.
The "creation date", as understood by 22 years of Mac users, is the
date that the CONTENTS of the file were created.
Then it's maintained about as well in that sense as it is in the
other; try this little experiment:
- create a document in, say, TextEdit and save it to a file.
- check the "file contents creation" date.
- open the file
- destroy its contents (select all, cut)
- create some new contents
- save them
To clarify, it's the date the contents were initially created. In the
above the file contents are only "created" once and are "replaced"
with other data.
Replacing the contents of a file is modifying the file, not
re-creating it. Hence it maintains the creation date as observed.
Note that the "file contents creation" time reflects the time that
the old contents were created, not the current contents, and thus in
this case the creation date refers to the container, not its
contents.
The "container", actually, might have changed. It could have
different attributes (e.g. ownerships) and the container could have
completely changed (as in copying to another volume). So it's clearly
not the container creation time, that would be btime.
Again, there is no analogous unix or POSIX time attribute for "Creation Date".
It's only in situations where the container is in fact *replaced*
("safe save") that you will see the creation date updated, and that
is an artefact, not intentional behaviour.
That would be the intentional Mac behavior as a "Save As..." is
obviously creating a new file from the original.
Strictly, the hair being split is "does copying imply duplication of
the contents, or the container"?
The Mac does not "copy" files. The parlance used is "duplicate", not
"copy". That is the file is cloned, replicated or duplicated and is
as the original.
One would naturally think that ditto would imply this behavior as
well -- since the word is defined as "duplicate" not "copy" -- but it
does not.
By my reading of your argument, you come down on the former side,
but would like applications to have some knowledge of the structure
and personal relevance of the content of a file. That last part's
hard.
It's not hard, it's been happening for 22 years.
The issue is why is copyfile, et cetera, placing the ctime in the
Creation Date attribute *as well* as Modified Date (where there's no
debate it belongs)?
Normally when systems lack the ability to express or are ignorant
regarding an attribute, they ignore it. If they fill it in it's
normally with a null or default value, like say zero or the beginning
of epoch. Duplicating
--
-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