Re: [WinMac] Re: Tar & archive formats

Michael Bartosh(bartosh[at]apple.tamu.edu)
Wed, 22 Sep 1999 11:00:18 -0500

> Actually, I believe it's *extremely* important to keep this
>thread going,
>because it is central to my recommendation to NOT deploy MacOS X Server.

Uhhh- OmniBackup??? Released 2 days ago???

> As long as there is NO viable - Read Mac-Friendly - backup solution, I
>will *not* recommend MacOS X Server. And as long as MacOS X Server runs on
>Apple hardware, with no PCI hardware RAID controllers, a rigorous backup
>schedule must be followed because of the lack of fault-tolerant disk storage.
>
> In short, these are the reasons why I do *NOT* recommend
>MacOS X Server.
>**IF** MacOS X Server would run on Alpha or x86/K7 hardware, then I would
>consider running it in locations that have a full time Unix administrator.
>
> Cheers!
> Dan
>
>At 10:42 AM 9/22/99 +0000, John Droggitis <johnd@cybernex.net> wrote:
> >Leonard Rosenthol wrote:
> >
> >> Exactly what I said above. It's a FLAT FILE structure based
> >> on pathnames rather than having actual "links" between a parent
> >> directory and it's children. And yes, each of those entries has a
> >> header with some basic information - but information that is
> >> incomplete for Unix, let alone other platforms (Wintel, MacOS, etc.).
> >
> >Right. I'm not arguing with your flat file assertion. What I'm saying is
>that
> >the there's nothing inadequate with using a flat file, as long as it
>contains all
> >needed information. And the information that it contains is not incomplete:
> ><geek> all the fields of the unix stat structure, which is the _complete_
>set of
> >file statistics, except the device specific details, are included in the tar
> >header </geek>.
> >
> >> Also, as I noted in my message, those pathnames are SHORT
> >> (100 characters), ASCII-based, which makes storing/restoring
> >> non-English filenames pretty much impossible. To use your
> >> reference, see
> >> <http://www.gnu.org/manual/tar/html_mono/tar.html#TOC112> and
> >> <http://www.gnu.org/manual/tar/html_mono/tar.html#TOC109>).
> >>
> >> GNU tar may support absolute pathnames, but it's not part of
> >> the POSIX spec for tar.
> >>
> >
> >GNU tar supports both absolute pathnames and (very) long filenames
>and paths.
> >POSIX specs don't consern me, it's the actual product you use that matters.
> >
> >> Let's also not forget about other well known limitations of
> >> Tar such as EXTREMELY poor recovery of corrupted archives, lack of a
> >> segmenting architecture, Unix-centricity, and of course no support
> >> for integrated compression (NOTE: .tgz is NOT integrated compression
> >> since it requires decompression of the entire archive before being
> >> able to extract a single item!)
> >
> >Look, I'm not saying that tar is the best archiver/backup solution. All I'm
> >trying to say is that tar is perfectly adequate. The original point that
>I was
> >refuting was "don't use unix as a fileserver because tar is no good", and
>it was
> >based on incorrect assertions about tar. Tar is very prevalent and
>widestpread,
> >has ports to every major platform and it supports features that stuffit and
> >retrospect don't have, but I REALLY don't want to get into that.
>Even if you
> >don't like tar, there are commercial solutions you can use for unix as
>well, such
> >as CTAR (which is based on tar :-) and solidstor.
> >
> >> As the original author of StuffIt Expander, and most of the
> >> components of the StuffIt Engine (incl. the Tar support) I stand by
> >> my categorization of Tar and it's (lack of) usefulness as a backup
> >> and archiving solution.
> >
> >Nice to see your credentials. I've been a software developer and
>administrator
> >primarily on unix machines for 10 years now, and I can read the tar source
>code
> >and understand it - and I have. I think I've proven my point and since
>this is
> >getting way off topic, let's continue this privately, but I really don't
>think
> >there's much left to say.
> >
> >--John
> >
> >
> >* Windows-MacOS Cooperation List *
> >
> >
>
> Yours truly,
> Daniel L. Schwartz,
> Electrical Engineer.
>
> Dan's MacOS Consulting
> 239 Great Road
> Maple Shade, NJ 08052-3044
>
> 856-642-7666 <-- Note new area code (was 609)
>
> -----------------------------------------------------------------
>
> THERE ARE NO ATTACHMENTS TO THIS MESSAGE, SO IF ONE
> APPEARS WITH IT, DO NOT OPEN OR DOWNLOAD IT!
> <mailto:expresso@snip.net>
>
> ALTERNATE: <mailto:expresso@workmail.com>
>
> Webmaster for <http://www.Faulknerstudios.com>,
> <http://www.BrakeAndGo.com>
>
> **Your UltraBac Solution Source**
>
>-> NEW! Sign up for the Mac-NT Mailing list at:
> <http://www.onelist.com/subscribe/Mac-NT>
>
> -----------------------------------------------------------------
>
>* Windows-MacOS Cooperation List *

* Windows-MacOS Cooperation List *

This archive was generated by hypermail 2.0b2 on Wed Sep 22 1999 - 09:05:17 PDT