Re: Standard OS X Compression format
Re: Standard OS X Compression format
- Subject: Re: Standard OS X Compression format
- From: Ondra Cada <email@hidden>
- Date: Sat, 17 Nov 2001 19:48:36 +0100
Marcel,
>
>>>>> Marcel Weiher (MW) wrote at Sat, 17 Nov 2001 16:00:54 +0100:
MW> >MW> This is essentially what the hfstar patch to gnutar does: for each
MW> >MW> <plain-file> archived, also archive '<plain-file>/rsrc'. Nothing
MW> >MW> special needs to be done when untarring, it just works.
MW> >
MW> >I don't think so.
MW>
MW> What you think doesn't really matter in this case:
Am I just unnaturally touchy today, or are you unneededly offensive?
MW> it *does* just work.
With some drawbacks which I felt considerable. Perhaps I am wrong and they
are not; let's see my reasons...
MW> >As I have recommended ages ago, I think it would be much
MW> >better to move those resource forks into a separate tree, rooted (using
MW> >some
MW> >*QUITE* distinctive name) in /tmp.
MW>
MW> "QUITE" distinctive names aren't good enough, because sooner or later,
MW> someone is going to stumble across that name.
Although in principle true, since you can select a _VERY_ distinctive one
(somewhere in proximity of "/tmp/...Mac OS X Very Special Gnutarred Rsrc
Forks Of <archive name>\1\2\3\4.!!!") the danger is really very, very remote.
OTOH, see (*) below.
MW> Also, I don't see how
MW> going to /tmp/ helps. As a matter of fact, I see going to /tmp/ as
MW> rather problematic. What if /tmp/ is a different filesystem?
With any non-"macgnutar"-aware system it would just serve as a trash;
therefore it is unimportant which filesystem it is placed in.
The real problems I see are
- unarchiving an archive which contains huge resource forks on a system
where the filesystem which contains /tmp has a little of free space;
- or on a system which is never ever rebooted and thus its /tmp might grow
really big.
I do admit those are *important* problems; just looked to me (again, perhaps
wrongly) as somewhat less important ones than those mentioned below.
Perhaps it would be better to archive resource forks a *very* special way,
something like "any resource fork is archived as a file named /dev/null,
whose beginning would contain a zero-terminated read file name". Those cases
would "macgnutar" interpret correctly (ie. restoring the resource fork of
that file), whilst any normal tar would just trash the data to /dev/null? I
don't know, and I've never tested whether it would work properly or not.
MW> >The reason is simple -- to make the archive easily and without confusion
MW> >useable worldwide. Should you try to unpack archive of your design on,
MW> >say,
MW> >Linux, you'll get a pretty mess.
MW>
MW> Not true. You will get warnings from tar but the resource forks will
MW> simply not be untarred.
Not if there happened to be a folder already, which happened to have the
same name as one of those unarchived files! That's the problem which I
(perhaps mistakenly) feel is worse than those of "mine" design, since
(i) this name clash is much more probable than the (*) one, since here you
can't limit the names: any name can be archived, any folder name can exist
already, and you can just _hope_ they are different;
(ii) what's worse, you won't be even warned that such problem occured! Of
course gnutar would emit the appropriate warning, but it will be hidden
amongst all those "normal" ones, caused by the "file" and "file/rsrc" being
in the archive.
MW> I have actually implemented this and tried it.
I've never said that it won't work; I just feel that this way is -- for the
(i) and (ii) reasons stated above -- more dangerous, with bigger probability
of data loss. It is quite possible I've overlooked something important, of
course: if so, just say what.
MW> >OTOH, should you unpack there "mine", you'll
MW> >get only some trash in /tmp, where it does not matter,
MW>
MW> I think no trash whatsoever and warnings on the console are a better
MW> solution.
Well, I guess what you think _does_ matter, but seems to me to be wrong in
this particular case (as anyone's is bound to be occassionally). IMHO a trash
is better than a danger of (unwarned!) data loss... but of course it is
possible that it's _mine_ thinking which is wrong this time!
Actually, I don't know the gnutar data format that well: isn't it possible
to embed arbitrary information of a file, which would be just ignored by any
tar which does not recognize the particular kind of information? If so, it
would be naturally the very best solution of our problem?
---
Ondra Cada
OCSoftware: email@hidden
http://www.ocs.cz
2K Development: email@hidden
http://www.2kdevelopment.cz
private email@hidden
http://www.ocs.cz/oc