From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.19-6.2.1 i686) Description of problem: The samba 'stat' call does not return consistent results. Immediatly after getting file information from a directory, the first file 'stat'ed gets one ctime. If the file is read and then a second 'stat' is done, the ctime usually differs by about 2 seconds. This originally manifested as tar printing spurious 'file changed as we read it' messages. This error occurs on wolverine (7.0.91) mounting a remote NT filesystem. I haven't currently found a 7.1 system with access to an NT Samba mount to test this on. How reproducible: Always Steps to Reproduce: cd to a samba directory, and run the following script: filecount=0 find . -type f -print | while read name ; do ls -la "`dirname "$name"`" > /dev/null stat "$name" | grep -v Access > /tmp/f1 filecount=$(( $filecount + 1 )) echo -n '#'$filecount' ' for i in 0 ; do for j in 0 1 ; do sleep 1 echo -n $i$j' ' cp /tmp/f1 /tmp/f2 wc "$name" > /dev/null stat "$name" | grep -v Access > /tmp/f1 diff /tmp/f1 /tmp/f2 || echo " ::::: ""$name" done done if [ $(( $filecount % 10 )) -eq 0 ] ;then echo ; fi done Actual Results: #1 00 5c5 < Change: Thu Mar 15 17:37:40 2001 --- > Change: Thu Mar 15 17:37:39 2001 ::::: ./ClientArchives/00-1081/a/00-1081a-cor.tif 01 #2 00 5c5 < Change: Thu Mar 15 17:39:48 2001 --- > Change: Thu Mar 15 17:39:47 2001 ::::: ./ClientArchives/00-1081/a/00-1081a-oth.tif 01 #3 00 5c5 < Change: Thu Mar 15 17:36:36 2001 --- > Change: Thu Mar 15 17:36:35 2001 ::::: ./ClientArchives/00-1081/a/00-1081a-rep.tif 01 #4 00 5c5 < Change: Sun Jul 16 12:47:52 2000 --- > Change: Sun Jul 16 12:47:50 2000 ::::: ./ClientArchives/00-1081/admin/00-1081-con.tif 01 Expected Results: #1 00 01 #2 00 01 #3 00 01 #4 00 01 #5 00 01 #6 00 01 #7 00 01 #8 00 01 #9 00 01 #10 00 01 #11 00 01 #12 00 01 #13 00 01 #14 00 01 #15 00 01 #16 00 01 #17 00 01 #18 00 ^C01 #19 00 Additional info:
We have loaded the latest redhat release on this system, and it is still exhibiting the same error. I have created a modified version of tar which checks mtime/size rather than ctime (apparently the old tar approach) using the option --check-mtime which seems to work around this problem as it affects tar.
The right thing to do would be fixing up the smb stat call, but unfortunately we can't fix NT. But I think some other users will run into the problem, so the tar switch may come handy. Please attach your patch.
I'm on RH9, and tar doesn't seem to be patched to include a --check-mtime option or equivalent. This seems like a worthwhile thing to add, as anyone who tries to back up smb shares with tar is likely to run in to the smb ctime problem. Currently, I work around it in my backup script by processing the stderr output of tar to see if the errors are innocuous (i.e., they are limited to "file changed as we read it" errors for files on smb mounts).
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. If this issue is still present in a current Fedora Core release, please open a new bug with the relevant information. Closing as CANTFIX.