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): 8.4 How reproducible: always 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/* . 3. Actual results: 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 Expected results: All files copied, no error messages Additional info: 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; 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.