Bug 604089

The error messages are from this test in cp (src/copy.c)

  /* Compare the source dev/ino from the open file to the incoming,
     saved ones obtained via a previous call to stat.  */
  if (! SAME_INODE (*src_sb, src_open_sb))
    {
      error (0, 0,
             _("skipping file %s, as it was replaced while being copied %d/%d %d/%d"),
             quote (src_name),(*src_sb).st_dev, (*src_sb).st_ino, src_open_sb.st_dev, src_open_sb.st_ino);
      return_val = false;
      goto close_src_desc;
    }

I added a printout of the values and got this:

skipping file x, as it was replaced while being copied 20/30681 20/1574355
skipping file y, as it was replaced while being copied 20/30682 20/12983805
skipping file z, as it was replaced while being copied 20/30683 20/13002682

The 20/1574355 etc numbers are verified to be the correct ones with ls -i

Did you try to mount it read-only?

If the read-only mount does not help, it looks like cifs variant of bug 501848

read-only makes no difference

cp is comparing dev/ino from a lstat with the values from a fstat (cp -a ...). 

The file system is ext4 on both servers. 
It appears that the problem occurs, when the file/file metadata is not in the Linux file system cache.

It is interesting to observe, that the device numbers are identical, but the inode number from lstat is just a counter being incremented by 1.

The problem seems to be located in the system somewhere below cp.

Does 'cp -L' make any difference?

Note you need to specify '-L' after '-a', it won't work well in the opposite order.

stat  --printf "%d\t%i\t%n\n" /mnt/vl/boot/vmlinuz
23      4853    /mnt/vl/boot/vmlinuz
stat -L  --printf "%d\t%i\t%n\n" /mnt/vl/boot/vmlinuz
23      21      /mnt/vl/boot/vmlinuz

stat  --printf "%d\t%i\t%n\n" /boot/vmlinuz
2049    12      /boot/vmlinuz
stat -L  --printf "%d\t%i\t%n\n" /boot/vmlinuz
2049    21      /boot/vmlinuz

The interesting thing here is, that the symbolic link inode is displayed as 4853 (a number closely related to the wrong numbers displayed in my test a  few moments before) when it should be 12 as displayed on the source server. This occurs for all the symlinks in /boot and is reproducible with the same inode numbers.

The cp -a -L will get the proper inode number.

I restarted smb/nmb on the source server: no change.
I unmounted/mounted and then the proper inode number was displayed for /mnt/vl/boot/vmlinuz. However not for /mnt/vl/boot/System.map, which had changed to a higher number in the skipped file sequence which again appeared on
/usr/src/other/co*5/src/cp -a  /mnt/vl/boot/ . after the mount.
Repeating this command got rid of the skipped files, but kept the wrong inode number for symlinks (except /mnt/vl/boot/vmlinuz which is now correct !).

(In reply to comment #5)
> stat  --printf "%d\t%i\t%n\n" /mnt/vl/boot/vmlinuz
> 23      4853    /mnt/vl/boot/vmlinuz
> stat -L  --printf "%d\t%i\t%n\n" /mnt/vl/boot/vmlinuz
> 23      21      /mnt/vl/boot/vmlinuz
> 
> stat  --printf "%d\t%i\t%n\n" /boot/vmlinuz
> 2049    12      /boot/vmlinuz
> stat -L  --printf "%d\t%i\t%n\n" /boot/vmlinuz
> 2049    21      /boot/vmlinuz

Did you try the same in different order?

> The cp -a -L will get the proper inode number.

That's probably the difference among stat/lstat syscalls.

> Repeating this command got rid of the skipped files, but kept the wrong inode
> number for symlinks (except /mnt/vl/boot/vmlinuz which is now correct !).    

I don't think I understand here.  The inode number can't be the same for src and dst.  On successful copy the new file gets assigned a new inode nubmer by the target filesystem.

Anyway this doesn't look like a coreutils problem as you can easily check by strace.  It must be a filesystem bug (or feature).

I am referring to the inode numbers as seen from the destination server and displayed by debugging statements I inserted into cp.

I agree, it is not a coreutils bug, but a BUG somewhere else. Is is definitely not at feature not being able to connct to a share and copy a file.

So ... should be reassigned to kernel?

(In reply to comment #8)
> So ... should be reassigned to kernel?    

+1, reassigning to kernel...

I have also reported it here:

https://bugzilla.samba.org/show_bug.cgi?id=7520

What kernel version does that happen on?
Does the cifs mount option "noserverino" make any difference?

Please, see the samba bugzilla, where a fix is being worked upon

Upstream bug closed as fixed. Closing this one with resolution of RAWHIDE.