Description of problem:
Files not copied from samba share on another Linux server
Very old problem which never seems to have been solved or has reappeared.
Similar operation between Fedora 12 and Fedora 6 servers did not exhibit the problem.
Version-Release number of selected component (if applicable):
Fresh Fedora 13 installation. Copying files from Fedora 12 server
Steps to Reproduce:
1.mount -t cifs //192.168.1.2/rootdir /mnt/vl --verbose -o password=xxx
2.cp -a /mnt/vl/root/* .
A lot of these error messages, but not for all files
cp: skipping file `/mnt/vl/root/rpmbuild/BUILD/kernel-2.6.32/linux-2.6.32.x86_64/sound/pcmcia/pdaudiocf/.snd-pdaudiocf.mod.o.cmd', as it was replaced while being copied
cp: skipping file `/mnt/vl/root/rpmbuild/BUILD/kernel-2.6.32/linux-2.6.32.x86_64/sound/pcmcia/pdaudiocf/pdaudiocf_pcm.c', as it was replaced while being copied
All files copied, no error messages
F13: samba 3.5.3-61.fc13
F12: samba 3.4.7-58.fc12
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;
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:
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.