[Samba] Re: File changed as we read it.....

[T. Shannon Gilvary]

David Sims wrote:
> Hi,
> 
>   This is probably a newbie question, but here goes. I am using samba to
> mount some windows box's hard drives to a linux box for the purpose of
> doing backups on the windows boxes. This is done late at night and I am
> SURE that no one is using the windows boxes....


I'm glad I'm not the only one having this problem.  I did a little 
digging....

Someone had mentioned that a previous version did not have the same 
problem, and I remembered I didn't have a problem until I upgraded to 
Slackware 8.1.  (I am currently running Samba 2.2.7a).

Tar 1.13 does not appear to have the problem although it's hard to 
verify[1].  However, Slackware comes with tar-1.13.25.  The code for the 
"file changed as we read it" error in tar-1.13 compares the mtime values 
and the file sizes (as reported by stat) before and after the read. 
tar-1.13.25 compares the ctime values only.  Now, in linux, the ctime 
value is modified whenever the inode is changed, but a stat on a samba 
share returns a ctime that is equivalent to the Windows "created on" 
timestamp.  As far as I know, these don't change as long as the file 
exists.  But, occasionally, the ctime value returned by stat is 
different, usually only by a few seconds, from the windows timestamp.  I 
have yet to see the same problem with the mtime or atime values.  On one 
particular file, tar gets the correct timestamp before the read and one 
off by two seconds after the read, thus triggering the error[2].

It seems there is a bug in the way samba shares report the ctime from 
stat.  Besides being inconsistently off, the functionality isn't the 
same from Windows to Linux.  The Linux ctime is an indication if the 
file has been changed rather than when it was created.  The next 
question is whether this is a problem in smbd or in the smbfs modules.

Shannon

[1] Changing the way you tell tar to backup the same files sometimes 
makes the error go away.
[2] this same file will report the correct ctime from an 'ls -lc' but 
will report two seconds fast from stat.