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

[daveman at bellatlantic.net]

On Fri, Dec 06, 2002 at 10:11:37AM -0700, Jacob Anawalt wrote:
> (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.
I am having this exact same problem, doing the exact same thing: backups. I simply assumed that it was just quirky, but it would be nice to be able to fix this. Very interested in hearing what you find out...

--David

> 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
> 
> 
> 
> 
> -- 
> To unsubscribe from this list go to the following URL and read the
> instructions:  http://lists.samba.org/mailman/listinfo/samba

-- 
 |\_/|
 (\ /)
  ) (//^\
 ( M )
(_)_(_)