[Samba] Re: Samba vs. Windows : significant difference in timestamp handling ?

[Failed Access]

f.pospischil at telenet-ag.de wrote:

> Hi there,
> 
> i still have a weird problem with Powerpoint an Excel files stored on a
> Samba share.
> 
> Only read on if you
> -use a samba share as MULTI-user file repository (no force_user etc.)
> -where multiple, different users share files in common directories
> -the modification time of a file is of any relevance to you.
> (seems like lots of folks don´t bother access rights or keep their
> information strictly user-wise organised ...)
> 
> Please look at the following example (Powerpoint 2000 and 2003 on
> Terminalserver and Standalone)
> 
> Timestamp history (on Samba share, 2.2.8a RedHat  Linux 9  with XFS
> 2.4.20-9SGI_XFS_1.2.0)
> File is initially created :
> Test.ppt mtime->12:40:05, ctime->12:40:05, atime->12:40:05
> File is then "viewed" (open in Powerpoint and exit without changing/saving
> anything) by same user:
> after file is opened:
> Test.ppt mtime->12:40:05, ctime->12:40:05, atime->12:45:59
> after file is closed:
> Test.ppt mtime->12:40:05, ctime->12:40:05, atime->12:45:59
> 
> Hmm, looks o.k. !
> 
> Now a different user "views" the file. (Different means, his username on 
> the
> Options-dialog in any Office-Application is different.)
> Can be faked by simply changing username in options-dialog in Word e.g in
> the same session.
> 
> while file is open:
> Test.ppt mtime->12:49:16, ctime->12:49:16, atime->12:49:16
> 
> oooops, looks like a new file ...
> 
> after file is closed:
> Test.ppt mtime->12:49:16, ctime->12:49:16, atime->12:49:16
> 
> ... still looks new to me !
> 
> Now the same procedure again,
> same environment except the file is stored on a Windows2000 Workstation
> (with NT file system tunneling disabled)
> 
> file create:
> size on disk: 8.192 bytes
> created  15:48:36
> modified 15:48:36
> accessed 15:48:36
> 
> "viewing" by the same "user"
> while file is open:
> size on disk: 8.192 bytes
> created  15:48:36
> modified 15:48:36
> accessed 15:48:36
> 
> file closed:
> size on disk: 8.192 bytes
> created  15:48:36
> modified 15:48:36
> accessed 15:48:36
> 
> O.K. that´s almost the same behavior that samba shows. (Except that on
> windows, the file doesn´t even look accessed)
> 
> Now change the Office-options to a different user and open the file:
> While open:
> size on disk: 12.288 bytes
> created  15:48:36
> modified 15:48:36
> accessed 15:50:30
> 
> WOW! the file is bigger though it was not modified and is still the one
> created 15:48:36
> 
> Now exit Powerpoint:
> size on disk: 12.288 bytes
> created  15:48:36
> modified 15:48:36
> accessed 15:50:30
> 
> ... still the same.
> 
> So on windows, the file seems now to be still the same version. (created
> 15:48:36 last modified 15:48:36).
> This is not true as Bits and Bytes are concerned but reflects the semantic
> of "open a file and exit without changing anything".
> 
> On the Samba share, the file looks like "brand new information".
> 
> I think that this makes a BIG difference on a shared filesystem where the
> modification time of a file serves as an indicator for the relevance of
> information.
> (Would you bother a file named "Hot_News" that was last modified 2 Years 
> ago
> ? And would you like this file to become "really actual" by open it with 
> the
> associated application and exit without saving/changing anything ?)
> 
> I think, Powerpoint (and Excel at least) store the initial timestamp and
> explicitly change them after the file is closed without "relevant" 
> changes.
> I suspect, the current user is written to the file so Powerpoint can
> announce: "File is currently opened by XYZ. Open it read-only?" or sth. 
> like
> that.
> The application tries to hide this change by doing some "magic" on the
> timestamps.
> 
> Question 1:
> Can somebody please confirm this behavior ?
> 
> Question 2:
> a) Does anybody know how the timestamp is changed (File system API, System
> API, magic spell ...) and why this mechanism fails on Linux/Samba/XFS ?
> (dos_filetimes parameter already set to yes)
> b) How can this be debugged efficiently in Samba ? (Log level 3 delivers
> tons of data, sth. like NT_STATUS not supported ... What is the meaning of
> the errors ? How to isolate the relevant entries ?where to begin ?)
> 
> Question 3:
> Is it possible to adjust samba to show the same behavior as NTFS ?
> 
> Any help concerning this nasty "bug" is really appreciated.
> After some months of preparation for the "big move" from Windows to Samba
> fileserver, this effect is a real show-stopper as most of the users rely 
> on
> the modification time for syncing information with Laptops, handhelds,
> project-lists and between each other.
> 
> Frank Pospischil
> Leiter IT
> Telenet AG Rhein-Main
> 
> Marburger Straße 14
> 64289 Darmstadt
> Germany
> 
> Tel.: +49 6151 733-353
> Fax.: +49 6151 733-325
> Web: http://www.telenet-ag.de
> 
> P.S.: Leser der deutschen Newsgroup de.comp.os.... mögen mir bitte die
> englische Variante verzeihen. Ist doch ein bisschen aufwändig das nochmal 
> in
> deutsch zu schreiben ...
> 
It looks like a windows/unix filesystem clash.
I can confirm the behaviour, ms word files are fine excel are rubbish 
only marketing use powerpoint so I couldn't tell on that.
Sorry to confirm the show stopper.
Can't be much help though.