What is needed to address bug#1601, Excel and Powerpoint file
dpullman at cme.nist.gov
Thu Feb 3 03:10:30 GMT 2005
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
>>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.
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!
More information about the samba-technical