Re: 'cp: .snapshot/xxx and xxx are identical'

[Paul Eggert]

Jim Meyering <address@hidden> 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.