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:27:36 -0400
At 7:55 PM -0700 8/11/06, Steve Checkoway wrote:
Dan Shoop wrote:
At 1:25 PM -0700 8/11/06, Steve Checkoway wrote:
This comes in handy if say, I have a bunch of documents in a
folder/directory and I want them sorted by when they were created,
not last modified, copied, backed up or munged. I simply enter list
view and click the "Creation Date" column and they're sorted.
Likewise I can look a a file's creation date and determine when the
document was created. I might have two different files name
"Christmas List" floating around and I want the one I created in
1997, not the one from last year.
Or I might have a bunch of pictures I took in a folder and I want
to find the ones I took back in 2001 on vacation. I might have
edited sometime later, but the modification date wouldn't reflect
when I captured those files. If I copied the photo to another
volume I still want to know when it was created, not when it was
copied.
But do you do this?
Yes.
When wearing my other hat, I'm a photographer. For my film based
photos these are filed by 'creation date', the date I took the
picture, and placed in my archives by this date and a reference
number (think of it as an inode). I also take digital photos and copy
these to my Mac in the Finder from the Flash Memory using the Finder.
The files on the Mac keep the creation date from the time when the
camera took the picture because that was the files creation date on
the camera. I copy them around in the Finder (and they maintain the
creation date accordingly.) I may scan film and will use a tool that
specifically sets the creation date to the date I specify. All is
well. Paradigms are preserved.
I then may retouch them in Photoshop and the get a new Modification
Date as expected. Sometimes I may create original digital artwork
from a photo and it get's, as expected, the date I created that work.
I may duplicate the file to other volumes or directories for backup
or to add it to other project's directories. I may need to change the
permissions on a file so to permit other workers to access the file.
However when I want to see or sort the pictures by when they were
created, I don't want the time I duplicated the file to the backup
volume or when I changed it's permissions to permit another to
access it. I want to look at the file, in the Finder, and know when
it was created, just like I and many others have been doing for 22
years.
If I move, duplicate or "backup" files to another volume in the
Finder or in an application it's not problem.
However drop down to the shell and rsync the files, tarball them, use
hdiutil or Disk Utility to create a disk image of the directory,
ditto them, cp them, etc and the Creation Date get's clobbered
because the unix dweebs[1] can't seem to see the difference between
the Mac's Creation Date metadata, as expressed through a long 22 year
history of properly expected behavior, and the POSIX concept of ctime
-- a completely different time value that has _no relation
whatsoever_ to creation date - so they clobber creation date to
preserve a distinctly different attribute, ghods know why. *That* is
improper behavior. If you want btime or ctime in the HFS[+]
filesystem, create btime or ctime metatdata. Don't, just b/c you have
no place to stick change time, stick the value in a perfectly useful
and already used attribute. If you need to invent some new file date
that is a new concept to HFS and the Mac then perhaps that's a good
use for the Attributes B-Tree. But an existing and well defined
attribute that bears no resemblence to change time is woolly
thinking. There's at least be somewhat of an argument, though still
at odds with the Mac's creation date schem, if if it was btime, but
it's not.
ctime was *never* creation date in unix, despite the fact that so
many people seem to believe this. So stuffing it in the creation date
file attribute on HFS[+] is not the right thing to do -- if for no
other reason than it breaks the 22 year expected behavior of the
Finder. And remember, it's the Finder, not the underlying shell, that
is "sold" to the user as their "experience".
Whole utilities exist to affect exactly this in the Finder such as
http://www.publicspace.net/ABetterFinderAttributes/ and is further
reinforced that people seem to expect this behavior such as this
user
http://www.ee.columbia.edu/~dpwe/resources/appledoubledates.html
If these utilities exist, what is the problem?
Because the unix underbelly of Darwin f*#cks them up.
This behavior is in current use by *millions* of Mac users daily,
perhaps not you or the recent unix converts. Theses Finder users
don't normally find this behavior disturbed b/c they rarely venture
into a shell and just copy their files using the Finder. Those that
do wonder WTF happened to their dates as we see repeatedly in
various forums where they "warn" users against "un-Mac like
behaviors" when copying files that cause these dates to be lost.
Millions, huh?
Yes, it's a very common practice to sort by creation date. I just
asked them all to raise their hands and we did a quick satellite
count.
That aside, I you seem to be lumping me in with some recent UNIX converts.
Not really.
As I've said, I've been using a Mac for 15 years. For some
perspective. I was 8 at the time we had our first computer, a Mac
Plus. It was not until my senior year of university that I ever used
a non Mac-UNIX.
To bad then, you missed out on a number of other OSen and filesystems
that have concepts of creation dates for far longer.
Just so you understand, I'm not some Mac zealot either. Far from it.
It use the Mac because it works and is a viable desktop machine. Well
one of my DEsktop platforms at least, but I don't carry my
AlphaStation with me very often or my Sparcs. My experience with
computer systems goes back to the 1970's and I've only lately (since
the early 1990's) come to the Mac. I routinely use and manage a wide
variety of systems and OSen.
Now I myself use various OSen, many others which also harbor the
concept of a file creation date, and while it may be hard for
unix-heads to get a grip on, users on OSen that support the concept
find it extremely useful.
It's not hard to get a grip on. I don't think anyone is confused.
There certainly appears to be. Perhaps not yourself
I think there's a confusion that ctime is some sort of "creation"
time and therefore is a nice candidate to get stuffed into HFS
creation date. It's not analogous at all. The analogous HFS attribute
is modified date.
IIRC ctime is already being polaced into the Modified Date. So why
munge it into the Creation Date?
The idea of using the creation date for backup utilities confused
me, I'll admit.
Probably b/c it's not or shouldn't be used for determinismm in backup
utilities.
Say I create file 1 in some folder. Then I create file 2 in some
other folder. Now, my backup software runs and makes a backup of
file 2. Next, I delete file 2 and copy file 1 into its place. The
backup runs, looks at the creation date and since it was before the
one in the archive, it doesn't bother to back it up. That seems
wrong.
It is wrong b/c you shouldn't be using that as a criteria for
determination. Which is why good Mac backup software doesn't either.
But note that if you indeed did create file 1 and then created file 2
they would have two different times anyway.
The file, as a filesystem object, is irrelevant to the user. The
user cares primarily about the contents.
You've never sorted a set of files by modification date? Or used
`find` to search for all the files by a given owner? Or cared about
file permissions or ownerships? Clearly file metadata is used by
users and sysadmins routinely.
Modification date, yes. All by a given owner, yes. File permissions
and ownership? Only when I have my sysadmin hat on.
Well believe it or not users also make use of modification date. The
may want to sort their files with the one's they've been working on
first.
Moreover it fails the "Mom Test", when a user sees "creation date"
in the Finder what do you think they suspect that means? The last
time the file was copied/touched or the time the file was created?
Ask your Mom what she think that means. Try to convince Steve Jobs
that it means "when the file was last copied", I doubt you'd win.
I'm not sure what my Mom would think. I can ask her.
I'm sure the answer would be telling.
It's incredulous to believe that anyone would posit that 'the
Finder's had this all wrong' for 22 years.
I didn't.
No, but certain engineers are implying this.
Moreover *this is the behavior of the Finder and the Macintosh
since its inception*. F%#king with it flies in the face of how the
Mac user interface is designed to function.
I didn't suggest doing any such thing. I believe you have put words
into my mouth.
Sorry if it seemed that way. I wasn't referring to you, necessarily,
but responding to the class of responses in general.
The only application I see that you've mentioned is sorting your
photos by date, even if you copy them.
Well I take photos. I have clients that have the documents they use
that they like to file my dates. These include a wide variety of
professions from video production, health care, finance, accounting,
education, ... and indeed I have other documents I sort by date.
Modification date lets me find the latest file attachments from my
emails quickly. Creation date lets me organize projects and code by
date.
It would never occur to me to do such a thing because I would have
put them in folders with the dates clearly labeled so that when I
sort the folders by name, it's all in order. That said, it seems
like a legitimate use. Not one I would use as an argument for
ensuring that creation date is inviolable.
No, it's not a reason why creation date is inviolable. The reason
it's inviolable is b/c that's how the filesystem has defined it.
Because that's how the Finder operates. Because the creation date is
not the ctime. Because that's what users expect follows from those.
The reasons why placing ctime in Creation Date is wrong are multiple.
The reasons why it's perceived as acceptable are suggest woolly
thinking.
--
-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