Path: utzoo!attcan!uunet!cs.utexas.edu!sun-barr!newstop!sunaus.oz!softway!cluster!necisa!boyd
From: boyd@necisa.ho.necisa.oz (Boyd Roberts)
Newsgroups: comp.unix.internals
Subject: Re: How do you find the symbolic links to files.
Message-ID: <1962@necisa.ho.necisa.oz>
Date: 12 Dec 90 23:21:38 GMT
References: <1990Dec7.192441.24778@dg-rtp.dg.com> <2469:Dec1001:13:4390@kramden.acf.nyu.edu> <1990Dec10.191522.2757@erg.sri.com> <2993:Dec1202:37:2090@kramden.acf.nyu.edu>
Organization: NEC Information Systems Australia Pty. Ltd.
Lines: 30

In article <2993:Dec1202:37:2090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>
>Right! So on a system with st_blocks, the archiver's responsibility is
>to restore the right number of holes. It can do this by making the first
>N zero-filled blocks into holes, with no regard to the original
>positions. This does *not* require access to the raw disk blocks.
>

Sounds like just the argument why you don't want st_blocks.  What a
nightmare to maintain from an archivers point of view.  Sure it can
detect the holes and diddle about, but that's revolting.

All you really want is the data in the file.  Using general purpose
archivers on special purpose (holed files) is just a no-no.  Programs
that create such files should also have programs to dump out the
data in the files, which can then be used to recreate them.

Dump and restor are special cases.  They archive file-systems and
it is their responsibility that the file-system structure is
preserved correctly.  Why System V deprecated them I'll never know.

I'm equally puzzled/appalled by those who advocate tar or cpio
to back up their file-systems.  Those things take an image of
a snapshot in time.  They don't handle incrementals or file
deletions properly.  They are used to archive -- not backup.


Boyd Roberts			boyd@necisa.ho.necisa.oz.au

``When the going gets wierd, the weird turn pro...''