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 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.

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.