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