les@chinet.chi.il.us (Leslie Mikesell) (02/02/90)
In article <741@visdc.UUCP> jiii@visdc.UUCP (John E Van Deusen III) writes: >>> $ find . -depth -print | cpio -o | tee /dev/ct | sum >>> $ cat /dev/ct | sum >> This won't work unless the the filesystem is read-only, since the >> read of each file will update the file's atime which will then be >> different in the next cpio stream. >You wouldn't use this to verify that a file system had been changed; >there are much better tools for that. Like looking at the ctime or mtimes? If you reinstall the cpio it will change the ctimes even though the filesystem contents are really the same. If you mv a file to a different name it will change the ctime but not the mtime (of the file). >I could be admonished for wasting >the access time information in making the backup, (use cpio -oa), but >this example was only for illustration. No, I was out to lunch on two counts there (as pointed out by C. Cahill) in that the tee example doesn't actually do 2 cpio's and cpio doesn't maintain the atime info in the archive anyway - it just sets it to match the stored mtime when you re-install. Note however, that using cpio -a will modify the ctime of a file as a side effect of trying to not modify the atime. This will prevent any reasonable use of ctime for incremental backups (which is necessary if you want to catch mv'ed files or files installed with cpio -im or anything else that knows how to maintain a file's real mtime.) The only "clean" way to get that effect is to mount the filesystem read-only which may not always be possible. >At first I was hard pressed to think of a good purpose for verifying >that the byte stream from cpio was identical to the byte stream read >from the tape at a later time. I've often wanted to know what files have changed since an archive tape was made (perhaps to update copies at another site). You can be fairly certain by comparing the names and inode info, but if you compress and uncompress some files you haven't really changed them but the ctimes will be modified. The GNUtar file-by-file comparison is a nice option to have available. Les Mikesell les@chinet.chi.il.us
roe@sobmips.UUCP (r.peterson) (02/04/90)
From article <1990Jan28.141935.24102@virtech.uucp>, by cpcahil@virtech.uucp (Conor P. Cahill): > > If all you want to do is verify that the files are on the tape you can > do the following: > > find . -depth -print | cpio -oBv > /dev/ct 2> /tmp/filelist > cpio -itB < /dev/ct > /tmp/filelist2 > diff /tmp/filelist /tmp/filelist2 > > This too depends upon the file system not changing. Not really. What you are comparing is the list of files that cpio generates as data goes onto the tape with the list you read back. These should always be identical (unless read errors occur). -- One makes strong assumptions delving Roe Peterson into the beginning of the universe... {uunet,mcgill-vision}!sobeco!roe - Stephen Hawking, Cambridge
roe@sobmips.UUCP (r.peterson) (02/04/90)
From article <737@visdc.UUCP>, by jiii@visdc.UUCP (John E Van Deusen III): > The real performance problems come from the the pipes, IPC. It was > bad form for me not to remove all that I could, (although I seem to > count just as many pipelines in the second version). In particular > dd if=/dev/ct bs=5120 | sum will never beat sum < /dev/ct. Probably not - if sum were smart enough to do block reads at the correct blocksize. Its' not. In fact, several tape device drivers that I've used forbid reads smaller than a block - as an attempt to reduce possible noise conditions, I believe. BSD43 unix is a perfect example of this. -- One makes strong assumptions delving Roe Peterson into the beginning of the universe... {uunet,mcgill-vision}!sobeco!roe - Stephen Hawking, Cambridge