Original inquiry:
> Does anyone have a utility, or a pointer to one, which will
> conveniently generate an index of a dump(8) tape, including file
> attributes, without having to extract the files?
>
> I expect to have to read the whole tape, since this info is probably
> dumped with the files rather than with the directories. The problem is
> not having a spare partition large enough to extract the whole tape
> into.
>
> The output from "restore tv" includes only the pathname and the
> i-number -- I need at least the "date written", and ideally would also
> like to get the size and the inode-changed date, for all "ordinary
> files" on the tape. (With the possible exception of the inode-changed
> date, this stuff has to be on the tape somewhere, since restore(8)
> restores it.)
So far I have received 5 pointers to a program named lldump, written by
Bill Heelan of McGill University. Three of these included the manpage,
which I have appended below. There was also a suggestion to use the -a
flag of dump(8); however this only works if -a was specified when the
dump was taken, and I suspect that it only saves the pathnames and
i-numbers since its purpose is to allow restore(8) to respond to its t
and i functions without having to read the tape.
I haven't got lldump yet, but it appears to be the answer.
Thanks to:
Simon Shickman <simon@horizon.huji.ac.il>
gauthier@fresnel.telecom.hydro.qc.ca (Jean-Benoit Gauthier)
James W.Williams <williams@nssdcs.gsfc.nasa.gov>
Randy Born <randy@ai.iit.nrc.ca>
jmcrowell@ucdavis.edu (John M. Crowell)
Daniel Quinlan <danq@lemond.colorado.edu>
Posting, including manpage:
To: sun-managers@eecs.nwu.edu
Subject: long listings of dump files
I've written a program to generate long listings (similar to ls) of
dump files. We've found it useful in determining exactly what is on
some tapes we are archiving.
I've compiled it under SunOS 4.1.1 with cc and gcc-1.40 and have tested
it on an Exabyte.
It is available via anonymous ftp from binkley.cs.mcgill.ca (132.206.51.9)
in the pub directory. Please ftp during off-peak hours (we are GMT -05).
Look at/edit the makefile before compiling.
The man page follows.
- Bill Heelan
wheelan@cs.mcgill.ca
------------------------------------------------------------------------------
LLDUMP(8) MAINTENANCE COMMANDS LLDUMP(8)
NAME
lldump - generate a long listing from a dump file
SYNOPSIS
lldump [ -a ] [ -d ] [ -f dump-file ] [ -s ]
DESCRIPTION
lldump prints, to stdout, a long listing (similar to that
generated by the ls(1) command) of a file created by
dump(8).
In particular, the listing of each file specifies its inode
number, mode, number of links, owner, group owner, size in
bytes, time(s) and the file name. Normally only the modifi-
cation time is given, but this may be changed by the -a
option. Unless modified by the -s option, times are given
in asctime(3) format.
Some lines in the listing may start with a plus sign, `+'.
This denotes a file that is on the dump tape by virtue of
having changed after the dump had started (in particular,
after the bitmap of files to dump had been created).
Also, some lines may begin with a hash sign, `#'. These are
comment lines and typically give such information as the
time of the dump, volume number, etc.
OPTIONS
-a All times. For each file in the listing, print the
modification, access and change times (in that order).
-d Debugging. Print debugging information.
-f Dump file. The argument, file-name, is the name of the
input file. If this argument is a dash, `-', or if
this option is not given, then input is taken from
stdin.
-s Seconds. Any times in the listing are given as seconds
from the epoch (in GMT).
SEE ALSO
dump(5), dump(8), restore(8)
BUGS
lldump currently only deals with dumps made from new format
file systems (i.e. dumps whose headers have the magic
number NFS MAGIC).
As well, it only handles dumps from machines whose byte
order is the same as the machine on which lldump was com-
piled.
AUTHOR
Bill Heelan
School of Computer Science
McGill University
Montreal, Quebec, Canada
------------------------------------------------------------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:43 CDT