What is needed to address bug#1601, Excel and Powerpoint file timestamp changes?

[David Pullman]

Jeremy Allison wrote:

>On Wed, Feb 02, 2005 at 05:06:43PM -0500, David Pullman wrote:
>
>  
>
>>I don't think so?  We have the default dos filetimes = no.  If I 
>>understand smb.conf(5), setting this to yes lets anyone besides the 
>>owner or root to change the timestamp.  The problem we're having that 
>>everyone besides the owner is changing the timestamp _now_, even with 
>>out that set to yes.  In other words, we already have too much time 
>>stamp change.
>>
>>It seems from empirical testing that the timestamp is not "reverting" as 
>>it does on the W2K server tests when the file is closed with no changes.
>>
>>Of course, with Windows it's hard to define what "no changes" means (ala 
>>the Word file switcheroo thing).  But what we mean by no changes is open 
>> the file, look at it and then do a file close.  No edits.
>>    
>>
>
>But if a new file is created, or a deliberate write is done, then the mtime
>*will* change. Now I found and fixed a bug for 3.0.11 where mtime changes made
>by the client prior to a write need to be "sticky" (ie. restored on close).
>
>This sounds like it will fix the problem exactly, so I'd strongly suggest
>you try 3.0.11.
>
>Jeremy.
>
>  
>
 I would expect if a write is done for some reason then the modification 
time would update.  But does this mean that if you have a file sitting 
on the exported file system and it is opened by the application, and 
then closed with no editing at all, that the modified time should 
change?  I wouldn't expect that from an app on a UNIX system, but I 
understand that SAMBA makes every effort to emulate Windows behaviour.  
But we tried it in the same cases on a Windows file server.  Upon 
opening the file the modified time would change to the time of open, but 
when closed it would revert to its original value.

One thing that we're having a little trouble tracking is that it would 
update sometimes when opened and then closed, but not other times.  It 
seems to be trying to change when opened by someone other than the last 
person who had it change.  Speculation ensued about maybe the app is 
trying to capture some sort of revision information, but we couldn't 
find it in any "document properties" or see it in file size changes.

In any case I did note your responses to other reports and that it 
sounded like what we're seeing.  I started a build of 3.0.11pre2 this 
evening and will try that out first thing in the morning.  When we tried 
the cases with 3.0.11rc1, we couldn't run the tests because no one in 
the files group membership, besides the file owner, could open the file 
with write privilege even with file mode of 666.  So we lost some time 
today chasing that around, but when we reverted back to 3.0.10 we could 
get group access again.  I'll get back to that tomorrow as well and if 
it repeats I'll report that separately.  Of course if your fix takes 
care of the mtime issue I'll report that promptly as well.

As always, thanks very much for the ongoing efforts with SAMBA, and also 
for taking the time to reply to my questions!

--David