At 10:38 AM -0600 1/2/02, Don Yuniskis wrote:
>> Donald Lee wrote:
>
>>If you want to restore a drive, I would suggest that you consider
>>using dump/restore rather than tar.  tar has some quirks, like
>
>That wouldn't allow him to "drop in" a base.tgz in place
>of the standard base.tgz and use the installer "out of the box"...
>
>>device files, empty directories, and permissions that make it
>>not a good match for "imaging".  dump/restore, although balky,
>>are built specifically for this task.
>
>
>Huh??  What am I missing?  I use tar all the time to build
>my backups...
>
>[snip snip]
>
>AFAIK, the only problems are (were?) named pipes and/or
>sockets being recreated as plain files (though that usually
>isn't a problem next time the program that created them starts
>up and erases/recreates them...)
>
>Are there some subtleties that I am not aware of here?
>
>I *do* know that tar isn't always tar (varieties).
>But, given that he isn't trying to move the tarball
>from machine/OS 1 to machine/OS 2, I don't see the
>problem... (?)

I didn't say that tar would not work for user data.  For backups, it
is fine.  Some of the things you apparently tested I have seen fail
on other tar implementations.  There are a couple out there.

I'm just suggesting that if you don't want to worry about details
like sockets and named pipes, and whether your tar(1) is up to snuff,
you should consider dump/restore because it is normally designed and maintained
specifically to restore _everything_ in a filesystem, including all
system specific quirks and kinks.

Sounds like other considerations dominate in this discussion anyway, so
it's not a reasonable choice.

-dgl-