How do you find the symbolic links to files.

Michael Richardson mcr at Latour.Sandelman.OCUnix.On.Ca
Fri Dec 14 08:42:56 AEST 1990


In article <2993:Dec1202:37:2090 at kramden.acf.nyu.edu> brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>Does anyone else understand the importance of restoring as much stat
>information as possible? It's an archiver's duty to do as good a job as
>it can.

  In theory, yes. 

>  1. On a system without st_blocks, an archiver can lseek past every
>     0-filled region. The system will automatically use holes wherever
>     possible. (A) This doesn't require raw disk access. (B) Since stat

  This sounds like the best solution overall. If the backup format
provides a method to store long sequences of zeros (either because
it supports holes, or because it does compression), it seems like a
good idea to use it. Most backing up is I/O bound (usually the tape)
(the common cptree alias is not a form of backup, so I don't feel badly about
making that take a little longer)

>  2. On a system with st_blocks, an archiver can lseek past the first
>     N 0-filled regions, enough to restore st_blocks; and then it can
>     write explicit zeros in the rest. Even if it doesn't know the block

  While I understand the desire to restore the file exactly the
way it was, I curious to hear an example of an application that cares
about st_blocks, that would mind having long sequences of zeros 
turned into holes. Other than such things as swap files or
other files that one might prefer to be contiguous, I can't see
a reason. (And if your OS supports contiguous files [e.g. RTU] 
then your backup utilities had better understand them...)
  "Just because I can't think a reason doesn't mean ..."


-- 
   :!mcr!:            |    The postmaster never          |  So much mail,
   Michael Richardson |            resolves twice.       |  so few cycles.
 mcr at julie.UUCP/michael at fts1.UUCP/mcr at doe.carleton.ca -- Domain address
    - Pay attention only to _MY_ opinions. -         registration in progress.



More information about the Comp.unix.internals mailing list