Re: Standard OS X Compression format
Re: Standard OS X Compression format
- Subject: Re: Standard OS X Compression format
- From: Marcel Weiher <email@hidden>
- Date: Tue, 20 Nov 2001 18:53:14 +0100
On Monday, November 19, 2001, at 07:13 PM, Gregory Block wrote:
I'd prefer ._file, personally.
Me, too. Unfortunately, Howard decided the other way.
My honest sticking point on this is that Finder implements using ._*
support
on non-forked filesystems, and automatically handles creating/destroying
these correctly when handled on them.
That is what it does. How is this a 'sticking point'?
So either deciding that ._* should be
supported, or that Finder needs to be changed to support the "standard"
method, seems to be the way forward on this particular issue.
I don't understand what you're saying here.
- On HFS+, the 'standard' way is to put the resource fork in the
resource fork
- On UFS, the 'standard' way is to put the resource for in a file
with '._' prefix
The second part is a *simulation* of resource forks handled by
higher-level code (Carbon) and has nothing to do with the low-level
file-system access that tools such as tar/pax perform. Darwin has no
idea whatsoever that a file with a '._' prefix is used by the
Finder/Carbon as a simulation of resource-forks.
For example:
marcel@spock[marcel]echo "Hi There" >._hithere
marcel@spock[marcel]cat ._hithere
Hi There
marcel@spock[marcel]cat hithere
cat: hithere: No such file or directory
marcel@spock[marcel]open -a TextEdit ._hithere
--> file opens up in TextEdit, text is changed ", wassup" is added
marcel@spock[marcel]cat ._hithere
Hi There, wassup
marcel@spock[marcel]cat hithere
cat: hithere: No such file or directory
marcel@spock[marcel]
Coming back to archiving, the simulated resource forks on a UFS
file-system can be archived with out-of-the-box archiving utilities such
as tar and pax, because everything is just plain files, the tools can
and should be blissfully unaware that Carbon/Finder are assigning
special meainigs to some of those files.
However, such utilities can't be used in a straightforward way to backup
files on HFS+ because they don't know or can't access the resource fork
or finder info. So such tools have to be adapted (or wrapped) in order
to obtain this additional information on HFS+. That is why hfstar and
hfspax exist.
The issues of modifying such utilities in order to allow them to archive
HFS+ volumes is orthogonal to the issue of converting between the
emulation done by Carbon/Finder and a real HFS+ volume. This, as I've
explained before, is not the business of an archival tool operating at
that level, but of a file-conversion/mapping tool. Just as 'helpfully'
mapping CR+LF to CR or vice versa is not the business of an archival
tool...
The reasons why are very similar for both cases: such a mapping alters
data in a non-safe way, meaning it might silently destroy data, which
just isn't what an archival tool should do if it can be avoided, and it
easily can be avoided.
Is Finder right or wrong?
In what way?
Does Finder plan on supporting other mechanisms?
What 'other' mechanisms? Putting resouces in the resource-fork? That
is fully supported.
Can someone from Apple comment on future or present Finder behavior with
regard to the way resource forks are handled on non-forked Fses?
Why would/should it change from what it is now?
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.