rcodi@yabbie.rmit.oz (Ian Donaldson) (11/08/87)
There is a bug in SVR2 cpio(1) whereby the modify-time of a destination file is set to that of the source file -regardless- of whether the copy was successful or not (eg: disk full). eg: find . -print | cpio -pdmv destdir might fail if the filesystem where destdir lives fills up. The copy the continues to completion, creating zero-length inodes giving many errors and copying nothing more. After making space on the destination filesystem, a subsequent copy does -nothing-, as all the destination inodes will exist and have the same modification times as the source inodes, but their content is grossly different! Until fixed, it was impossible to tell which files weren't copied properly, unless you diff'd the source and destination, or were looking at the error output of cpio in the first pass! A fix is simply to check for write-errors during the copy, and if there were any, don't update the modify/access times on the destination. Thus, they will be left at the current time. A subsequent run will refuse to copy files to newer versions (that are truncated). In retrospect the failed destination times probably really should be reset to 0:0:0 1/1/70, so that no manual intervention is necessary before redoing the copy (except of course those commands needed to make some space on the destination filsystem). This might cause unforseen problems, so I didn't do it this way. Maybe cpio should also check the file-size when updating trees? This way it -would- know if a file has been truncated during a copy. This bug is present in SVR2 cpio, and also SunOS 3.3 cpio (for those using the optional Sun SVR2 packages). Ian D