Re: First timer: Finder Copy vs. cp
Re: First timer: Finder Copy vs. cp
- Subject: Re: First timer: Finder Copy vs. cp
- From: Jeffrey Ellis <email@hidden>
- Date: Sat, 12 Aug 2006 19:31:59 -0700
- Thread-topic: First timer: Finder Copy vs. cp
on 8/12/06 12:02 PM, email@hidden at
email@hidden 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
>
> 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. 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.
>
> Strictly, the hair being split is "does copying imply duplication of
> the contents, or the container"? 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.
>
>> The file, as a filesystem object, is irrelevant to the user. The
>> user cares primarily about the contents.
>
> Happily, the system stores lots of data that is "irrelevant to the
> user". If it didn't, life would be very unpleasant. 8)
>
> = Mike
Hi, Mike--
I didn't mean to start anything by this question. I'm creating an app that
copies some files using the command line. I know that many, if not all, of
our users will complain about our copy procedure if it doesn't retain the
metadata in the same form as the expected behavior of the Finder.
I understand that systems operate differently, and there are valid reasons
for each to function in the way it does. And I think you present a very
logical argument that a copy of a file is not in fact the file itself, but
an entirely new document. And I'm willing to agree that the creation date
has no relevance to the contents of the file.
But as reasonable as those ideas may be, it's just not the way Apple's
Finder works. There, a copy of a file retains the creation date of the
original. That decision was made by Apple many years ago, and unless I want
to argue the case to Steve Jobs, that is simply the choice I must follow.
They could have said that copying files creates blue cows in the metadata
for that matter.
Consistency with expected behavior is one of the basics of good design. At
the moment, the command line does not provide a way for us to develop our
software to meet either the expectations of our users, or to be consistent
with Apple's own design.
As one of the folks involved in copyfile, I hope you might come to see the
difficulty of the position Apple is placing it's developers in this area. If
Users expect blue cows in their metadata, Apple shouldn't prevent us from
being able to provide them.
All My Best,
Jeffrey
_______________________________________________
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