[Samba] modification time inconsistency
AndyLiebman at aol.com
Fri Jul 13 14:35:45 GMT 2007
jra at samba.org wrote:
> On Wed, Jul 11, 2007 at 12:14:19PM -0400, Chris Smith wrote:
>> On Thursday 21 June 2007, Carlos Knowlton wrote:
>>> I have a client with a windows utility that relies on "touch"ing (changing
>>> the mod time) on zero-length files in a folder for the purpose of judging
>>> when that folder was last accessed. This works fine for him on mapped
>>> windows servers, and from the local disk, but from a Samba (v3.0.22)
>>> volume, the mod time doesn't change unless there was an actual data change
>>> within the file. (ie, clicking "save" in notepad doesn't change the mod
>>> time unless he enters some data first.).
>> Tried this out of curiosity and find the same results. It only happens with a
>> zero length file, if the file has any data in it then the timestamp does
>> change by doing a save in notepad (no data change necessary). With a zero
>> length file it doesn't change when the file is on a Samba share.
>> However with a cifs mounted Samba share a "touch filename" does update the
>> timestamp even for zero length files.
> I've fixed this for 3.0.25c and later.
Any possibility this timestamp issue could be related to an issue I see
when accessing Samba 3.0.23d (or 3.0.13 for that matter) from an OS X
10.4.x machine running Thursby's DAVE?
There is a specific video editing application that runs on OS X. The
application creates a pair of database files (two files) on every volume
where audio and video media are store. One file is the actual database.
One is a very small file that basically records when the last change was
made to the database and how many files should be there. Every time you
start the video application, the small file is "touched" (even if its
contents are not modified). I reckon the application is "marking" when
the last time was that it looked at this file. The problem is, the
timestamp on the small file usually gets set to the "workstation time"
and not to the "server time", whereas the "big file" always gets set to
the "server time".
If the two times are out of sync, the application can get into a vicious
circle in which every time it boots, it sees that the "mtime" of the
"small file" is earlier than the mtime of the "big database file" -- and
the application thinks this means it has to remake the "big database
file". On the next start of the application, the same happens again.
(This never happens on the Windows XP version of the application, by the
Having both server and workstation time exactly synchronized seems to
aleviate the problem on OS X. However, it's difficult to enforce what
users do to their workstations in terms of configuring NTP.
Has something changed in Samba 3.0.25c that would cause the mtimes to
always be "server time"? We don't see this issue with Apple's "native"
SMB client, but then again the native client has some serious
performance issues so that's why we don't use it.
More information about the samba