[Samba] Re: Create time changing by itself?
Jacob Anawalt
anawaltaj at hotmail.com
Sat Dec 21 01:16:00 GMT 2002
>Find fs/smbfs/proc.c in your kernel source tree.
>Search for smb_proc_close_inode().
>See if changing any of the operations it does there helps.
> - remove the code after the "Kludge alert"
I did this, and still tar thinks the file was modified. Now I'm seeing the
ctime drift like Timo noticed when I stat. The first stat showed one ctime
and then the next and subsequent stat's showed an mtime 2 seconds into the
future from the first. They were all even second mtimes.
> - remove smb_proc_setattr_ext()
I skipped this and went to the next step, then came back to this step.
Everything seems to be the same. I get the file changed as we read it msg
while in the create stage, and Mod time differs while in the verify stage.
> - replace ino->i_mtime in the smb_proc_close() call with a 0
I did this, now when I open the files, mtime is set to epoch for the unix
machine's view, and some 2106 date on the w2k machine. when tar'ing
sometimes it sees the file as epoch, and sometimes it sees it as a day or a
month before epoch (1970-01-01). Even using sysopen() or open() O_RDONLY in
a perl script modifies the mtime. I realy didn't expect a file open in
readonly to change the mtime. An interesting thing was that shelling `stat`
immediatly after the open() or even the close() calls in the perl script
still showed the old mtime, but calling stat from the command line after the
script exited showed the modified to epoch mtime.
After trying all of the above, I re-compiled one more time, commenting out
the DSET call in smb_proc_close. The problem is still there, and mtime is
getting set, but now to wierd values, different months in 2019 as reported
from the linux side. One time I run it and they are set to Jul 10, another
time to Aug 25th. So, if the mtime isn't set by smb_proc_close call,
something else is setting it?
What are the reasons for the following questions, or where can I find the
answers:
Why are SMB timestamps are only accurate to two seconds?
Why is the mtime modified even if the file is open in O_RDONLY?
Where (else) can I look to see why the results of an lstat are always
different than an mstat through smbfs mounts?
"Urban Widmark" <urban at teststation.com> wrote in message
news:Pine.LNX.4.44.0212182207040.19290-100000 at cola.enlightnet.local...
> On 16 Dec 2002, Timo Sirainen wrote:
>
> > Are there some known problems related to ctime changing by itself? I
> > didn't find anything with google at least. tar seems to be complaining
> > about it all the time:
> >
> > [cras at hurina] ~% tar cf test.tar /mnt/cygwin/home
> > tar: Removing leading `/' from member names
> > tar: /mnt/cygwin/home/Timo Sirainen/xxx/xxxxx.xxx: file changed as we
read it
>
> Yes, this is known. smbfs does some strange time operations when closing a
> file. I think the idea is to make sure the time is changed when a file has
> been written to (NT4 doesn't, or not always?).
>
>
> I had someone that I thought I had tricked into testing this but I haven't
> heard anything for a while. The relevant code is (probably) this
> file/function in the kernel source tree:
>
> fs/smbfs/proc.c:smb_proc_close_inode()
>
> Try removing the "Kludge alert" parts and if that fails, the
> smb_proc_setattr_ext() call.
>
>
> Or wait until I get around to it.
>
> /Urban
>
> --
> 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