Jim Meyering <[EMAIL PROTECTED]> writes: > You could try comparing the entire `struct stat's of two file/snapshot > pairs, one where the snapshot is the same, the other where it differs, > in the hopes that there will be something obvious that distinguishes > the two cases.
The only difference that I found was the st_atime field. For example: $ ls -ltu .addressbook .snapshot/*/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 7 15:00 .snapshot/hourly.0/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 7 13:00 .snapshot/hourly.1/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 7 11:00 .snapshot/hourly.2/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 7 09:00 .snapshot/hourly.3/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 7 00:00 .snapshot/weekly.0/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 6 23:00 .snapshot/hourly.4/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 6 21:01 .snapshot/hourly.5/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 6 19:00 .snapshot/hourly.6/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 6 17:00 .snapshot/hourly.7/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 6 00:00 .snapshot/nightly.0/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 5 00:01 .snapshot/nightly.1/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 4 00:00 .snapshot/nightly.2/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 3 00:00 .snapshot/nightly.3/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 2 00:00 .snapshot/nightly.4/.addressbook -rw-r--r-- 1 eggert fac 0 Mar 1 00:00 .snapshot/nightly.5/.addressbook -rw-r--r-- 1 eggert fac 0 Feb 28 00:00 .snapshot/weekly.1/.addressbook -rw-r--r-- 1 eggert fac 0 Feb 27 00:00 .snapshot/nightly.6/.addressbook -rw-r--r-- 1 eggert fac 0 Feb 26 00:01 .snapshot/nightly.7/.addressbook -rw-r--r-- 1 eggert fac 0 Jan 21 12:32 .addressbook But it's a bit flaky to rely on st_atime. For one thing, it'll cause misbehavior on non-broken hosts, if some other process is currently reading the files being copied. Also, it wouldn't fix the problem for the non-Netapp file systems where this might be an issue. I was hoping that perhaps some system call other than "stat" could be used. (What, I don't know.) Here's another idea, if we can't find out directly. Use the following heuristic: 1. If the dev+ino differ, or if their file types differ, or if they are not regular files, then assume the files differ. 2. If the stat info shows their file system is neither NFS nor MVFS, assume they are the same. (If the stat info does not report file system type, skip this step.) 3. Use futimens to slightly perturb the destination's last-modified time (e.g., add 1 unless that would overflow; otherwise subtract 1). 4. See whether that change is reflected in the source file's status. If so, assume they're the same file, undo the perturbation, and quit. Otherwise assume it's a buggy file system and they are not the same file, so go ahead and copy. 5. If anything fails in steps (3) or (4), assume they're the same file. That conforms to POSIX better, and should be good enough in practice. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
