Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!uwm.edu!linac!att!princeton!njsmu!telesci!frnkmth!bill
From: bill@franklin.com (bill)
Newsgroups: comp.unix.sysv386
Subject: Re: fsck Recovery From Crashes
Keywords: inode file directory lost+found
Message-ID: <8Jun91.185243.7766@franklin.com>
Date: 8 Jun 91 18:52:43 GMT
Article-I.D.: franklin.8Jun91.185243.7766
References: <1991Jun4.020353.11910@newshost.anu.edu.au> <4Jun91.144729.1340@franklin.com> <1991Jun6.070129.4796@newshost.anu.edu.au>
Organization: Franklin Electronic Publishers
Lines: 52

In article <1991Jun6.070129.4796@newshost.anu.edu.au> cmf851@anu.oz.au (Albert Langer) writes:
: In article <4Jun91.144729.1340@franklin.com> bill@franklin.com (bill) writes:
: >: I have an awk script adapted from one by Tony Moraes, which
: >: converts an ls -alR listing into the same style as "find".
: >: It would be easy to use ls -ailR and include the inode number
: >: in the output and sort on that.
: >
: >Urk. Why go to all the hassle?
: >
: >     find $dir -mount -print | xargs ls -di
: >
: >gets you inode,file in a neat listing.
:
: True. The awk script was developed for processing the output of
: ftp ls commands where it is only possible to run ls but not find.
: (It also processes dates into a uniform sortable format instead
: of the different handling of recent and ancient dates by ls -l).

That solves a different problem and is probably overkill, though
the date sorting is nice. I wish ls had an option to force a
uniform output. Sigh.

: While it would not be worth writing for the inode directory, I
: imagine it is probably more efficient than running ls on each
: small batch of file names with xarg.

You end up reloading /bin/ls every N files, as compared to the
inefficiency of using awk. (Which is *really* awful if you don't
have a coprocessor.) If /bin/ls is chmod +t, this cost is very
small. Also, you'd probably do a bit more I/O in the pipe with
your method.

Which is better can't be decided a priori; measurement seems in
order but has to be done on the target system.

: I also suggested the find -ls option which would be yet more
: efficient where available and ff which would be the
: most efficient.

Yes. Where available. Find -ls isn't on SysV<4 systems (maybe on
SysV4); ff is on mine, anyway, but I have no idea whether it is
more efficient, nor if it is a standard. Also, ff uses the `ftw'
package, I understand, and that will barf if your hierarchies go
sufficiently deep.

: Don't forget he's planning to run this every day on every file.

Unless he's got a humongous partition, this is probably
irrelevant. I already do several finds each day on my file
systems, though for different reasons. (One, the "skulker" to
trash old cores and a.outs, and another to collect statistics.)
These run very quickly, even with my 272M of disk.