Hi,

How does tar's -W (verify) option work? Does it:

1) Restore entire archive to local temp directory and expect
original files to exist on disk to compare against?

2) Restore entire archive to local temp directory, but assume that
the read process itself would show up any errors?

3) Restore file-by-file to local storage, comparing against original
files?

4) Restore file-by-file to local storage, but with no comparison?

5) Restore block-by-block to memory only, with no need for local storage
at all?

Unfortunately both the man page and info text just say "verifies the
archive" without saying exactly what the process is. In an ideal world I'd
restore the whole lot myself to a temp directory and checksum against
original data using cksum just for peace of mind, but I don't have enough
free disk space to do that :-) With that in mind, option 5 above would be
best - providing there's no chance that reads are successful but
transparently returning garbled data (I'm not sure what, if any,
checksumming either tar or the underlying DLT media has)

What are other people doing to verify tar archives? In the past I've
generally just done a read-back of archive contents with the 't' option,
but I suspect that may only show up errors in the header for each file
and could possibly miss errors in pure data areas...

cheers

Jules

--
we've fallen off the silly boat into a sea of ridiculousness!

Jules <julesrichardsonuk@remove.this.yahoo.co.uk> writes:

[snip]
> What are other people doing to verify tar archives? In the past I've
> generally just done a read-back of archive contents with the 't' option,
> but I suspect that may only show up errors in the header for each file
> and could possibly miss errors in pure data areas...

Maybe 'tar -d' does what you want?

--
... __o Øyvind
... _`\(, http://www.darkside.no/olr/
... (_)/(_) ... biciclare necesse est ...

In article <pan.2006.12.30.14.45.07.766567@remove.this.yahoo. co.uk>,
Jules <julesrichardsonuk@remove.this.yahoo.co.uk> wrote:
> Hi,
>
> How does tar's -W (verify) option work? Does it:
>
> 1) Restore entire archive to local temp directory and expect
> original files to exist on disk to compare against?
>
> 2) Restore entire archive to local temp directory, but assume that
> the read process itself would show up any errors?
>
> 3) Restore file-by-file to local storage, comparing against original
> files?
>
> 4) Restore file-by-file to local storage, but with no comparison?
>
> 5) Restore block-by-block to memory only, with no need for local storage
> at all?

It doesn't appear there's any writing-to-disk involved. I ran 'tar -d
$file.tar. in one rxvt window, and 'watch "lsof 2> /dev/null | grep
tar"' in another, and saw:

(CMD PID USER FD TYPE DEVICE SIZE NODE NAME)
tar 16106 eben cwd DIR 22,3 4096 605078 /usr/tmp
tar 16106 eben rtd DIR 22,2 4096 2 /
tar 16106 eben txt REG 22,2 189472 372387 /bin/tar
tar 16106 eben mem REG 0,0 0 [heap] (stat: No such file or directory)
tar 16106 eben mem REG 22,2 86676 371917 /lib/tls/i686/cmov/libpthread-2.3.5.so
tar 16106 eben mem REG 22,2 1226096 371904 /lib/tls/i686/cmov/libc-2.3.5.so
tar 16106 eben mem REG 22,2 28244 371919 /lib/tls/i686/cmov/librt-2.3.5.so
tar 16106 eben mem REG 22,2 86596 48687 /lib/ld-2.3.5.so
tar 16106 eben 0u CHR 136,9 11 /dev/pts/9
tar 16106 eben 1u CHR 136,9 11 /dev/pts/9
tar 16106 eben 2u CHR 136,9 11 /dev/pts/9

STDOUT points to its TTY, and there's no other FD.

--
-eben QebWenE01R@vTerYizUonI.nOetP royalty.no-ip.org:81
> A: It's annoying as hell
> Q: Why do most people hate top-posting? -- Lots42 The Library Avenger
http://www.fscked.co.uk/writing/top-posting-cuss.html

On Sat, 30 Dec 2006 16:32:33 +0100, Øyvind Røtvold wrote:

> Jules <julesrichardsonuk@remove.this.yahoo.co.uk> writes:
>
> [snip]
>> What are other people doing to verify tar archives? In the past I've
>> generally just done a read-back of archive contents with the 't' option,
>> but I suspect that may only show up errors in the header for each file
>> and could possibly miss errors in pure data areas...
>
> Maybe 'tar -d' does what you want?

Yep, it appears to, although I'm not sure what the behaviour is if it
finds an error. I'll have to do a small test archive and deliberately
"corrupt" a file on tape (by changing the corresponding file on disk) to
see what it does...

Interestingly, using the 'verify' option (rather than --compare / -d)
seems to give strange behaviour (GNU tar 1.15.1). I just wrote one archive
to tape, which then verified OK, then I rewound the tape and
forward-spaced one file (both via mt) to make sure I was beyond the end of
the first archive. Then I wrote a second archive (all of this is using the
non-rewinding device, obviously) - but and at the end of this the verify
stage is trying to verify the *first* archive once again.

It's almost as though the verify option issues a 'rewind' command
before verifying, rather than back-spacing to the start of the archive
which was just written - either that or it tried to do a back-space and
completely missed the tape mark at the start of the second archive for
some reason.

Based on that observation though, it looks like '-d' ('--compare') is a
better bet than '-W' ('--verify') for multi-archive tapes, as I can use mt
to get to the right position on tape and then use tar to do the compare
from there.

cheers

Jules


--
we've fallen off the silly boat into a sea of ridiculousness!