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: Wed, 28 Nov 2001 15:28:20 +0100
On Thursday, November 22, 2001, at 11:49 AM, Gregory Block wrote:
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,
Absolutely fine. In fact, non-HFS filesystems are supported fine by
plain gnutar even without hfs-extensions.
What is your point?
[snip]
So as an archive/unarchive format, you succeed
1. tar/gnutar already has 'succeeded' as an archive/unarchive format
2. I am not interested in 'success'. hfstar is not a product, I have no
mission for it. It serves a single useful function, and I have
decided
to share my work.
in doing so only when the filesystem remains within the "island" of
MacOS support.
Completely false.
You don't support
the use of unarchived files on many of the filesystems supported by
MacOS X
Completely false.
- as most of those are flat filesystems or are network filesystems which
also happen to be flat.
Exactly, which means they are supported just fine both by plain tar and
by hfstar, because hfstar includes all of plain tar WITHOUT BREAKING
BACKWARDS COMPATIBILITY. Your proposal *would* break backwards
compatibility, which is why I did not go that route despite considering
it.
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.
False.
What, exactly, is the value of spending a million hours worth of
discussion
Good question. The hfstar-extensions are probably less code than what
you have written so far in trying the "explain" to me how stupid I am.
The source code to hfstar is available: go ahead and implement what you
think should be done. Then come back and tell me how stupid I am. (I
have a feeling you will have a better understanding of the issues once
you've actually tried to put them into code..._
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.
Hfstar serves my needs just fine. You are free to add to it.
So, it's simple. If you want to support *users*, who are expected to
*use* this stuff, without pushing HFS
False. hfstar does not "push" HFS at all. You can archive/unarchive
UFS filesystems with all the Carbon/Finder resource simulation just
fine, JUST LIKE YOU CAN WITH PLAIN (GNU-)TAR.
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.
That was a polite way of saying: you are not making sense. It seems
that such courtesy is a wasted effort.
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.
Obviously not. Go ahead and implement your suggestion. You will then
notice that it is not backwards compatible and will, in fact, silently
destroy data.
And *what they exist for*, in my humble and most honest opinion, is to
support
the operating system's,
Yes.
and in this case Carbon's specifically,
Nope. Carbon is not the operating system. Carbon is a library
implemented on top of the operating system. Hfstar is implemented on a
layer below the Carbon layer. Referencing Carbon from such a tool would
violate the layering of the OS.
Discuss.
representation of a file, of which it has two: Resource forks on a
forked
filesystem and ._* on a non-forked one.
Both of which are supported.
The only thing not supported is automatic conversion between these two
representations.
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.
You are not making sense. (Since you don't seem to understand the more
polite form).
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.
You are not making sense.
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.
Then why are you doing it?
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.
Fully agreed. This is why I see hfstar as a stopgap measure until we
can all live happily without such a tool and plain (gnu-)tar etc.
This does not, however, turn the idea of using a naming scheme that can
and will cause collisions into a good one.
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.
You are, again, misunderstanding the issue.
From usability,
In your not so very humble opinion. I would call this convenience, and
I agree that what you are proposing would be more convenient for the
case where you want to move data between HFS+ and UFS filesystems.
However, I rate *safety* much more highly in a backup tool than
convenience features, and what you propose just happens to be seriously
non-safe.
If you want the convenience, nobody is stopping you.
unless you're using ._*, you're just yet another nonstandard
archive format
False. The archive format is quite standard. It is just some of the
contents that cannot be interpreted on some file-systems. You would
find it convenient for the archiver to perform such a conversion for
you. I agree that this would be convenient, but don't consider that the
convenience it would offer outweighs the impacts on safety.
that leaves my files useless on foreign filesystems,
False.
and there's quite a few of those out there already, thankyouverymuch.
Youreverywelcome. If hfstar isn't useful for you, don't use it.
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,
Huh? What other representation should they have used?
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.
It is now my fault that Apple chose a particular representation and
doesn't fully support non-forked file-systems? What color is the sky on
your planet?
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.