On Wed, 2002-01-02 at 11:38, 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"...
> 

exactly. any other solution would require a bootable NetBSD partition to
'bring the system up'. With this solution you could probably make a
bootable MacOS CD that restores your system.

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

I stand corrected. As you said, tar is not always tar, and I have to
admit I just was not sure if the options were available to keep the
attributes of the device files. I work mainly on linux now for my day to
day stuff, and only run machines that have to be reliable on NetBSD
;)...

Richie


  
> # cd /dev
> # mkdir emptydir
> # touch emptyfile
> # tar cpf XXX *
> # tar tvpf XXX	
> 
> -r-xr-xr-x root/wheel    12597 Aug 23 04:45 2001 MAKEDEV
> -r-xr-xr-x root/wheel     2100 Aug 23 04:45 2001 MAKEDEV.local
> lrwx------ root/wheel        0 Sep 25 19:01 2001 apm -> tctrl0
> ^ symlink preserved (not followed)
> 
> crw-r--r-- root/wheel     71,8 Sep 25 19:01 2001 apmctl
> ^ character device
> 
> crw-rw-rw- root/wheel   69,128 Sep 25 19:00 2001 audio
> crw-rw-rw- root/wheel   69,128 Sep 25 19:00 2001 audio0
> crw-rw-rw- root/wheel   69,129 Sep 25 19:00 2001 audio1
> 
> [snip]
> 
> crw------- uucp/wheel     12,3 Sep 25 18:59 2001 dtyd
> ^^^^^^^^^^ preserved permissions
> 
> crw-r----- root/kmem      3,11 Sep 25 18:59 2001 eeprom
>            ^^^^^^^^^ preserved owner/group
> 
> drwxr-xr-x root/wheel        0 Jan  2 09:20 2002 emptydir/
> ^ *empty* directory
> 
> -rw-r--r-- root/wheel        0 Jan  2 09:23 2002 emptyfile
> ^ *empty* file
> 
> crw-rw---- root/operator  18,3 Sep 25 19:00 2001 enrst0
> crw-rw---- root/operator 18,19 Sep 25 19:00 2001 enrst1
> brw-rw---- root/operator  11,3 Sep 25 19:00 2001 enst0
> ^ block device
> 
> brw-rw---- root/operator 11,19 Sep 25 19:00 2001 enst1
> crw-rw---- root/operator  18,2 Sep 25 19:00 2001 erst0
> crw-rw---- root/operator 18,18 Sep 25 19:00 2001 erst1
> brw-rw---- root/operator  11,2 Sep 25 19:00 2001 est0
> brw-rw---- root/operator 11,18 Sep 25 19:00 2001 est1
> crw-rw-rw- root/wheel     22,0 Sep 25 18:59 2001 fb
> drwxr-xr-x root/wheel        0 Jan  2 09:21 2002 fd/
> crw-rw-rw- root/wheel     24,0 Sep 25 18:59 2001 fd/0
> crw-rw-rw- root/wheel     24,1 Sep 25 18:59 2001 fd/1
> 
> [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... (?)
> 
> --don
> 
>