Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Standard OS X Compression format

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.

References: 
 >Re: Standard OS X Compression format (From: Gregory Block <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.