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:58:13 +0100
On Thursday, November 22, 2001, at 11:51 AM, Gregory Block wrote:
[soapBox setNeedsDisplay:YES]
On 20/11/01 12:54 pm, "Marcel Weiher" <email@hidden> wrote:
Yes, I see the attraction of this, and I must admit I am attracted as
well. However, this is a translation of a native file-system format to
a simulation of that file-system format. While a nice feature, that is
the task of a different program.
So, what you're telling me is that unlike a zip archive, or an ordinary
tar,
an hfstar archive is really only valuable to a user of UFS and network
filesystems when he or she chooses to use an HFS disk to unarchive to.
No. An hfstar archive is just as valuable as an ordinary (gnu)tar
archive for UFS + network filesystems, because on these filesystems all
the "special" information is stored in plain files that is handled just
as well by hfstar as it is by (gnu)tar. Of course, there is no need for
hfstar in these situations at all because (gnu)tar is fully sufficient.
While there are a lot of arguments you can make for choosing not to
support
._*, I don't believe the one you just made was a very good one.
It would be great if you understood the issues first before making
judgements.
If your goal is backup and restore, then is it okay to demand that the
restore media be an identical filesystem to the backed up source?
Essentially: yes. If the restore-media does not have certain
facilities of the originally backed-up media, then it is not the
archiver's job to compensate. It is especially not the job of the
archiver to write an archive that will be guaranteed to restore on
less-capable systems.
For example: should filenames be truncated to 32 characters in case
someone decides to 'restore' on plain HFS? Or converted to 8.3
uppercase in case someone decides to unarchive on DOS/FAT? Or should
names be mangled in the way that Windows uses to represent long
filenames? I think the answer is "no" in all these cases, and also in
this one.
If that's okay, then you have a pretty good argument for saying that
you've got a good
backup/restore mechanism.
I don't *have* a good backup/restore mechanism. I have created a
*small* patch to basic gnutar in order to make it usable for rich HFS+
files. Considering this, I think it is much more important to make sure
existing functionality doesn't break rather than achieving maximum
convenience. What you are asking for breaks basic, existing
functionality in non-obvious ways.
It turns out that I hardly every actually need this, because my backups
of variable data almost invariably involve plain (non-forked) files and
plain gnutar does just fine for those. Most forked files I encounter
are either system files or applications that would be re-installed from
source anyhow and need not be backed up.
However, as a more "living" work, where people
archive and unarchive their work on a regular or semi-regular basis, I
think
you can understand why demanding Finder compatibility is arguably one
of the
most difficult user demands to meet, and also one of the most attractive
features, regardless of the difficulties one might have.
Essentially: Anyone who isn't support ._* isn't supporting
finder-level use
of the information on anything but an HFS disk.
False. Or rather: ._* is supported just fine both in hfstar and in
basic (gnu)tar, even though you fail to understand this.
What isn't supported is automatic conversion between the HFS+
representation and the non-HFS+ representations. There are several
reasons for not supporting this, having to do with (a) scope (b)
layering and most importantly (c) safety and backwards compatibility.
Tell me how the work you've done has gotten the community *ANY
FURTHER* than StuffIt
1. Tell me how the work you've not done has gotten "the community" ANY
FURTHER at all.
2. It allows you to back up and restore all the file-system info on
both HFS+ and UFS + other non-forked filesystems,
and do so from a shell, remotely, via crontab.
- which, much like
your solutions, archive and unarchive HFS filesystems just fine, and
leave
them useless on non-HFS filesystems.
False.
What we need is something
What *you* need, or rather think you need. Hfstar fills *my* needs just
fine, thankyouverymuch, and also seems to work for quite a few other
people, who actually understand its real limitations.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.