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: Sat, 17 Nov 2001 21:04:14 +0100
On Saturday, November 17, 2001, at 07:48 PM, Ondra Cada wrote:
[distinctive filenames]
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.
- any 'special' filename you come up with will at some time be used
- especially in automation scenarios, think of recursion!
- 'magic' values that 'never' happen are time bombs, because they
*will* happen
(anybody remember the nice programming perl on a program that
maintained
information about capital cities but always bombed on
international data,
South America to be precise... ? )
- a long prefix is going to impose filename length restrictions
- gnutar doesn't allow absolute path-names in archives and will strip
them, so /tmp/ simply won't work.
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.\
Speaking of which, I very often do my compressing/uncompressing in
/tmp...
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.
Yup.
I do admit those are *important* problems; just looked to me (again,
perhaps
wrongly) as somewhat less important ones than those mentioned below.
We'll see.
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".
My scheme already accomplishes that and matches the scheme used by Apple
for implementing HFS+. Think about that.
[hfstar will cause mess on other systems]
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!
I don't see this as a problem at all. Untaring a *file* over a
*directory* already is an error condition. If you're relying on tar to
behave in a specific way in error-conditions, you are definitely asking
for trouble.
That's the problem which I
(perhaps mistakenly) feel is worse than those of "mine" design, since
Yes, I believe you are mistaken about that.
(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;
Huh? If I go to my root directory and as root untar an archive contain
a file named 'bin', I am asking for trouble anyhow. I don't see how
this is more "probable".
(ii) what's worse, you won't be even warned that such problem occured!
Yes you would! You would get an error that you just tried to write a
plain file where a directory already existed.
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.
So you're going to have a file named 'rsrc' in a directory that by
rights could have been completely clobbered. Whew.
MW> I have actually implemented this and tried it.
I've never said that it won't work;
I said this works and you said you "didn't think so". That is why you
got a harsh reaction: it does work. Plain and simple. Wether you like
the solution is a different matter.
I just feel that this way is -- for the
(i) and (ii) reasons stated above -- more dangerous, with bigger
probability
of data loss.
So far, you arguments haven't been very convincing.
It is quite possible I've overlooked something important, of
course: if so, just say what.
Yes. It won't work, at least not with gnutar, which strips out absolute
paths. Furthermore, it can still lead to name-clashes and data-loss in
*non-error* situations and restricts filename length.
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,
Your opinion doesn't matter in deciding wether something works when
quite clearly it does...
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...
On some systems, /tmp is mounted on the same partition as swap, so you
could unwittingly fill up swap and cause a system crash, especially
since the operator would be unaware that you're dumping gigabytes of
information into /tmp.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.