matthiasm (mm@matthiasm.com) wrote:
> Yes, creating eternal chaos. If you were to copy a file by name, the
> resource fork would not be copied. Even the original OS X "tar",
> "cp", "mv", etc. commands (until 10.2) did not know about resource
> forks and destroy applications.
True, but all of that just applies to the shell. Most users never touch
that anyway. Before Mac OS X, there was no shell, and you could count on
the Finder to do the right thing. Of course, the Finder still does the
right thing, only differently. That's why you can put files with
resource forks on a FAT-formatted USB stick and read them intact on
another Mac -- provided that both Macs run under Mac OS X, or both run
under Mac OS. But try to exchange files between Mac OS X and Mac OS, and
it won't work: Mac OS doesn't recognize the resource forks stored by Mac
OS X, and vice versa.
> The command line "ftp" that came with OS X did not do that. I have
> not checked after 10.1, but I doubt it would.
That's entirely possible; command line tools usually know zilch about
the Mac. But who would use a Unix command line tool when there are
powerful FTP clients such as Interarchy etc.? All the popular FTP
clients on the Mac have always known about resource forks and how to
deal with them.
But to return to the issue of .zip vs. .sit: when Mac OS X creates
a .zip archive from a folder, it will preserve the resource forks. It
will create an archive containing two folders, one with the data forks
and one with the resource forks. Mac OS X deals with these
transparently, but users of other operating systems will wonder what all
those funny files prefixed by "._" are supposed to be.
- Michael
Michael J. Hußmann
E-mail: michael@michael-hussmann.de
WWW (personal): http://michael-hussmann.de
WWW (professional): http://digicam-experts.de
-- This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries Official Newton FAQ: http://www.chuma.org/newton/faq/ WikiWikiNewt for all kinds of articles: http://tools.unna.org/wikiwikinewt/Received on Thu Mar 22 19:36:12 2007
This archive was generated by hypermail 2.1.8 : Fri Mar 23 2007 - 09:30:00 EDT