[Samba] Re: Re: File changed as we read it.....
Jacob Anawalt
anawaltaj at hotmail.com
Tue Dec 10 19:39:01 GMT 2002
So, I try playing with smbtar from the RedHat 7.3 samba-client-2.2.7-1.7.3
rpm and it decides to ignore the incremental command, yet when I connect
with the smbclient interactive session and use the tar command, incremental
(g) works.
smbtar -i -v -a -s post -p <password> -x qbooks -t
test-arc-inc_qbooks_smbtar.tar
server is post
share is qbooks\\
tar args is ga
tape is test-arc-inc_qbooks_smbtar.tar
blocksize is
added interface ip=192.168.0.9 bcast=192.168.0.255 nmask=255.255.255.0
Domain=[OFFICE] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]
tarmode is now full, system, hidden, reset, verbose
vs:
smbclient //post/qbooks
added interface ip=192.168.0.9 bcast=192.168.0.255 nmask=255.255.255.0
Password:
Domain=[OFFICE] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]
smb: \> tar cga test-arc-inc-maybe_qbooks_smbtar.tar
directory \bkups gecko\
directory \INET\
directory \old Gecko\
directory \qbooks\
directory \qbooks\INET\
tar: dumped 5 files and directories
Total bytes written: 0
It seems smbtar passes -c 'tarmode full' even if you use the -i(incremental)
option. So, I've modified my smbtar script to change clientargs to "-c
'tarmode inc'" when the [i]ncremental option is given. I don't know how this
is different than just removing the clientargs command completely, other
than with the command in verbose mode it echos the nice 'tarmode is now bla,
bla, bla' string.
I'm posting the smbtar script fix info in a new message so it is easier to
find. I've checked the CVSweb and the file has the bug and hasn't been
modified for almost three years.
Jacob Anawalt
"Jacob Anawalt" <anawaltaj at hotmail.com> wrote in message
news:at5apv$4gu$1 at main.gmane.org...
> Well, the silence towards my issue with the mtime thing was starting to
make
> me thing I was going about things all wrong or something, so I decided to
> try smbtar. It is a script that wraps the smbclient connection and tar
> command available within an smbclient session.
>
> The first thing I checked was the timestamp reported in an smbclient
> session, it was the 58 seconds timestamp that ls and a second or later
stat
> reports for the file via an smbfs mount instead of the 57 seconds
timestamp
> that windows, tar's first scan, and the first stat of a day report. The
> smbclient tar command ran on the file without any complaints.
>
> Using this tar does give me the ability to do 'windows style' incremental
> backups, based on the state of the archive bit (set/checked = back me up,
> I've been changed) bit. I dont see a verify option for the smbclient tar
> (v2.2.7) which I will miss. I was also trying to work with the GNU tar
> listed incremental option, but again perhapse I should just use the
archive
> bit. When in Rome...
>
> Still, if someone knowledgeable with and working on the smbfs code (or
> wherever the mtime code is) would look into the mtime drift, I'd
appreciate
> it. I have more details in my post from 5 Dec 2002: Re: SMBFS files
> receiving incorrect timestamps
>
> Jacob
>
>
> <daveman at bellatlantic.net> wrote in message
> news:20021206222744.GB5883 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 )
> > (_)_(_)
> > --
> > 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
>
More information about the samba
mailing list