Re: Behaviour on crash of editors, Tar/Gzip, and teaching UNIX at UNI

Today, Richard Corfield <Richard.Corfield.Admin-XZoyATsUNX5Wk0Htik3J/[email protected]> wrote:
> On Tar/GZ
> ---------
>
> As for Tar not Zipping - its separation of concerns, a common design
> principle. UNIX utilities are designed to be small tools that are very
> good at their job. You combine them together with pipes and shell
> scripting to get the whole job done. Tar knows how to make a tape
> archive. GZip knows how to compress data, or you could use BZip2, or
> CPIO instead of Tar. 

Yeah. Tar knows how to make a tape archive; gzip knows how to compress
data. So both combined know how to compress a tape archive. Great, but
for storage on tapes, another thing is important: How do you create a
tape archive of compressed data? In pseudomathematical/functional terms:

tar & gzip gives you:
compress(archive(data));
But, when backing up to tapes, you want:
archive(compress(data));

In no way can you make a standard unix tar do that. So, a compressed TAR
archive has a few unhealthy properties: if only one bit in the tape is
flipped, the rest of the backup is all lost due to checksum errors. You
can have either compression /or/ safe storage on tapes.

In that regard, I can recommend afbackup, which does the right thing and
compresses only the file contents. So, when your tapes break, only the
files which failed checksum checks, but not the whole backup is lost. (:

> You could pipe through GPG for encryption if you want, send it over a
> network or all sorts. Traditional UNIX, everything is a file, you take
> input from somewhere, pipe it through whatever and send it somewhere
> else. Because everything speaks the same simple interface (the file IO
> calls), you have a lot of flexibility.

And in traditional unix, the writer of the software doesn't expect that
things break. If they do, it's the user's fault. (-;

It's a really nice approach if you want to modify data that are kept in
a simple line-oriented format. Name four not in: /etc/passwd,
/etc/group, /etc/shadow. Not even C programs or shell data are sensibly
processable using that method. Try programmatically changing an
identifier "is" to "p_is" in C code but not in comments. (-:

> This way may seem hard to a Windows user, but small components are
> more reliable. Also consider the situation where you may be running
> (say) a database and some other system on a box. Both need to send
> emails to administrators in certain situations. Both have their own
> way of setting up and doing it. On UNIX you can call an external
> command, use the system mailer, whatever. Its so much more flexible,
> and also can be made so much more consistant. (Also note how on UNIX,
> so many things speak the same mailbox format)

Oh, the mailbox format that insists on making lines like:
From starts with a >?

I wrote "From starts with a >?". You are most likely to see
">From starts with a >?". This is due to the "must remember to think
before I type" format called mbox. It separates messages with lines
starting with "From sender date", so that you don't get to start lines
with "From" in your message bodies. Your friendly, ever-so-foresightly
written mailer replaces it with ">From", for your convenience.

Wheee, isn't unix fun,
-- 
Andreas Fuchs, <[email protected]>, [email protected], antifuchs
(yes, it isn't fun)