[Samba] modification time inconsistency

[AndyLiebman]

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.
>
> Jeremy.
>   
Hello Jeremy,

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 
way.)

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.

Regards,
Andy