On Fri, Dec 06, 2002 at 10:11:37AM -0700, Jacob Anawalt wrote: > (I have sent this to [EMAIL PROTECTED] 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" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > 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 ) (_)_(_) -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba