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
On Mon, 28 Oct 2002, Kris Kelley wrote:> 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.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 ...> 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)?No idea. Never heard anything like it before and would guess that the client time actually was wrong (at that particular time). /Urban
Jacob Anawalt
2002-Dec-05 23:44 UTC
[Samba] Re: SMBFS files receiving incorrect timestamps
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
Urban Widmark
2002-Dec-18 22:02 UTC
[Samba] Re: SMBFS files receiving incorrect timestamps
On Thu, 5 Dec 2002, Jacob Anawalt wrote:> tar: <filename>: file changed as we read it...> 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.I posted something regarding this just now, but here is a repeat: 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" - remove smb_proc_setattr_ext() - replace ino->i_mtime in the smb_proc_close() call with a 0 I have been a bit busy recently but I will eventually get around to looking more closely at this. /Urban