Re: Standard OS X Compression format

• Subject: Re: Standard OS X Compression format
• From: Marcel Weiher <email@hidden>
• Date: Sat, 17 Nov 2001 21:04:14 +0100

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

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

• Prev by Date: Re: &xxx; thingies
• Next by Date: Re: IB Palette with a Window
• Previous by thread: Re: Standard OS X Compression format
• Next by thread: Re: Standard OS X Compression format
• Index(es):
  • Date
  • Thread