Re: Standard OS X Compression format
Re: Standard OS X Compression format
- Subject: Re: Standard OS X Compression format
- From: Gregory Block <email@hidden>
- Date: Thu, 22 Nov 2001 10:49:54 +0000
On 20/11/01 5:53 pm, "Marcel Weiher" <email@hidden> wrote:
>
> 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'?
Define how you're supporting the use of non-HFS filesystems, or any
real-world network use through non-AppleTalk networks. Fact is, Finder has
a representation, and Carbon allows applications to use that representation
on non-forked filesystems.
So as an archive/unarchive format, you succeed in doing so only when the
filesystem remains within the "island" of MacOS support. You don't support
the use of unarchived files on many of the filesystems supported by MacOS X
- as most of those are flat filesystems or are network filesystems which
also happen to be flat. Finder supports them, Carbon supports them, and if
I drag a file over, then my system can use them, but if I make the stupid
mistake of archiving it on HFS instead of archiving it on that UFS disk
after a finder copy, your application is going to leave me without the
information.
What, exactly, is the value of spending a million hours worth of discussion
at such a low level that you miss the fact that real-world users who expect
to use these tools would also like to see a bit of unity in what their
system can and can't do with these files. So, it's simple. If you want to
support *users*, who are expected to *use* this stuff, without pushing HFS
and AppleTalk down the throats of people who choose not tor or cannot use
it, then either ask to have Finder and Carbon changed to support Yet Another
Format Because We Can't Agree On What Color The Sky Is, or support ._*.
Discuss.
>
I don't understand what you're saying here.
You do now.
>
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.
(Just so everyone knows) Yes, I'm fully aware of the technical issues. And
*what they exist for*, in my humble and most honest opinion, is to support
the operating system's, and in this case Carbon's specifically,
representation of a file, of which it has two: Resource forks on a forked
filesystem and ._* on a non-forked one.
>
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.
And since Finder performs that job today, I will argue that Finder should
gain that "file-mapping" to the flat filesystem support. And since Apple
has so many free, clueless resources who have nothing better to do than
watch a bunch of people banter whether or not to store in filesystem-illegal
directories or name-colliding file mappings, why don't we just document them
all and have Apple implement each of them. After all, you must *all* be
Right.
Apple decided on the standard filesystem format on non-forked filesystems.
Arguing over whether or not it's perfect, or whether or not to use it, is
just wasted time and effort.
>
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.
HFS itself has case issues that cause that damage - on this, everyone has a
glass house.
Decide on what issues you think you're solving - as neither tar nor pax,
non-hfs versions, provide any protection for that problem on HFS. From
usability, unless you're using ._*, you're just yet another nonstandard
archive format that leaves my files useless on foreign filesystems, and
there's quite a few of those out there already, thankyouverymuch.
>
Why would/should it change from what it is now?
Because they've clearly made some grave error in deciding to use that
representation on non-HFS filesystems, or we'd see tools that support the
great effort that Apple has done to ensure that files and applications with
resource forks can actually be *used* on non-HFS filesystems. If only you'd
told them that they were wasting their time sooner, they could have saved
time and money.