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

[Jacob Anawalt]

(I have sent this to dpsims at virtualdave.com as well)

David,

I'm dealing with the same thing. I just posted yesterday asking about it.
I'll put the contents of my post here, but a quick summary of what I found
is that sometimes the mtime reports itself as one value and sometimes as
another value for a few of the files I access. For whatever reason tar is
getting the right value when it starts making the archive, but as it reads
the file it sees that smbfs is reporting a new time (in my case the new
mtime was one second later than the correct mtime.) Hopefully someone will
have an answer for one of our posts.
The error isn't critical, which is why tar finishes the archive and gives an
exit delayed message, but it is frustrating because I don't know without
investigating if it is a file that hasn't been modified for months, or if
some program realy did change the contents of the file as I was tarring it.
Even if a program did though, I believe you get the copy of the file as it
was before the mtime changed.
Ps. I access the newsgroup using gmane.org (news.gmane.org :
gmane.network.samba.general). It's a nice way to read the posts you want
without getting tons of email all day like you do with a mailing list.

"David Sims" <dpsims at virtualdave.com> wrote in message
news:Pine.LNX.4.21.0212060443490.2621-100000 at ernie.virtualdave.com...

> 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....
>
> While backing up I often see tar complain as
> follows: "tar: IssRating/C4dll.dll: file changed as we read it" or
> "tar: MPLUTIL/AUTO/TXOLD/AUTOMENU.EXE: file changed as we read it"
>
>
> What is causing these files to change??? Why would an executable or a
> dll change???
>
> Please reply via e-mail as I am not a list subscriber.
>
> Tia.
>
> Dave
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: http://lists.samba.org/mailman/listinfo/samba
>

My Post:  Re: SMBFS files receiving incorrect timestamps (Dec 5 2002)

Hi,

My tar (GNU tar) 1.13.25 on a RedHat 7.3 Linux system has been giving me non
fatal, but discouraging messages for some time now as I try to archive files
across smb mounts to a Windows 2000 Server system. it doesn't happen with
all files, fortunatly, but it does happen with a few files per archive.

tar: <filename>: file changed as we read it

The strange thing was when I would look at the files the mtime (on either
system) was several months old. Today I dug deeper because I am increasing
the number of files that I am backing up across the smb mounts.

What I found was that without fail, tar would get one mtime value when it
started reading the file, but that time must have drifted while reading the
file, hence the message.

mtime tar puts into the archive: (no matter how many times I run tar)
2002-01-30 13:41:57
This is the same value reported by the file properties on the Windows 2k
server.

mtime ls -l --full-time reports
Wed Jan 30 13:41:58 2002

The first time I ran stat (after tarring the file a few times) it reported:
Wed Jan 30 13:41:57 2002
I ran it again, immediatly after that output, and it reported:
Wed Jan 30 13:41:58 2002

stat continues to report this value no matter even after running tar again,
which continues to put the (correct) Wed Jan 30 13:41:57 2002 value into the
archive

When I copied (cp -a) the file from the smb mount to the local ext3 fs, the
mtime was Wed Jan 30 13:41:58 2002 (incorrect)

Now, one second isn't any big deal except that tar sees it as a change and
then I have to track down and see if tar realy got the right version of the
file(s) (maybe the file wasn't months old).

I have tried remounting, and that didn't help.

Other program versions:
kernel 2.4.18-3
samba 2.2.7-1.7.3
stat: 2.5-5
ls (GNU fileutils) 4.1
mount 2.11n-12.7.3

I found this thread in the archives in October 2002, and it seems slightly
related. I gather from the reply that smbfs is actualy managing the mtime
values instead of passing on what it reads from the remote file system? If
so, is there one library call (the one tar uses for the archive headers)
that returns the right mtime, and another (the one tar uses to see the file
has changed and that ls -l uses) that returns the wrong mtime? More likely
by some wierd twist tar always gets smbfs to report the right time at first
but then as the file is accessed (read by tar, ls) smbfs is then reporting
the wrong mtime?

Any suggested work-arounds in configuration settings are appreciated. Maybe
when someone is going over the timestamp code, they might use this
information to fix the glitch (if it is in the smbfs/smb mount)

Jacob Anawalt

On Mon, 28 Oct 2002, Urban Widmark wrote:
smbfs sets the mtimes itself. Not really sure why it was done like that, but
some comments claim that NT4 doesn't set mtime properly otherwise. It would
be better to just let the server handle time.
The 1-hour diff is probably the daylight savings change. smbfs is told by
smbmount what the server timezone is, as minutes from GMT. Of course this
changes with the daylight savings ...
On Mon, 28 Oct 2002, Kris Kelley wrote:
Hello all.
Our system consists of two linux machines, each running Red Hat 7.1 (kernel
2.4.9-34), using SMB to mount multiple shares hosted by a Windows 2000
Advance Server. smbclient from Samba 2.2.5 is used to do the actual
mounting.
Over the weekend, a number of files on these SMBFS shares were created with
incorrect timestamps (modification times). In some cases, the timestamps
were off by as much as four days! Today, every file created by the linux
machines, even those created by "touch" called without any extra arguments,
received timestamps that were one hour ahead.
When I discovered this was happening, I unmounted all SMBFS shares, and
remounted them. This fixed the problem; all files created now have the
correct timestamp.
The Windows host and the linux clients all have their system clocks set
correctly, and their system clocks were updated automatically during the
switch from daylight savings time. I suspect the 1-hour discrepancy I saw
today has something to do with the daylight savings switch, but if that is
the case, what caused some files created on Saturday (26
October) to receive timestamps for this coming Wednesday (30 October)?
Most importantly, how do I keep this from happening again? Please let me
know if more information is needed. Thank you.
---Kris Kelley



--
To unsubscribe from this list go to the following URL and read the
instructions: http://lists.samba.org/mailman/listinfo/samba