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

Dragan Krnic dkrnic at lycos.com
Tue Aug 12 18:31:30 GMT 2003

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

Why would you do that?

|> 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 !

Not my experience. Even after doing the fake number
the mtime remains unmodified, atime gets changed, of
course, and, what was not quite to expect, so does
the ctime.

Probably because, should the other user have changed 
anything and re-saved the file it would have belonged
to him now. So PPT first changed ctime when it was
quasi given over to the new user and then it changed 
back to original owner again when it was clear that 
the other user wouldn't commit his changes.

Sounds like some sorts of attributes not supported by

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

This can't be. But if it works like this, then it is
a bug in MS Windows. Or a feature, if you so will.

|> Now change the Office-options to a different user 
|> and open the file:

Again, why would you do that? What happens when another
user logs in on that or any other PC and opens/closes?

|> 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 ?

At least a part is confirmed by me. I still don't see
where it will come to play a big role. After a year
with samba with lots of .doc's, .xls's, .mdb's and 
.ppt's being churned out by programs automatically
my users, who are very dependent on these documents,
never ran into any problems. Perhaps because we use 
reiserfs and because we don't fake. :-)
|> 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)

Leave dos filetimes alone. They're about another bug
in MS FAT where they tried to squeeze the time in too 
narrow a bit space so that they had to drop the lsb
in effect counting only the even seconds of a day.

|> 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 ?)

Trust the source, Fritz. Acquaint yourself with that
part of samba. Do logs and pore over them by candle
ligt. After some time it won't be chinese any more.

|> Question 3:
|> Is it possible to adjust samba to show the same 
|> behavior as NTFS ?

Of course. You're the best one to do it. I might 
lend you a helping hand but the problem is not as much 
a show-stopper for me as it is for you. Do the right

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

It is a matter of perception. I'm sure this weird 
behaviour will not really cause nearly as much 
problems as you might think it would. It's not a show-
stopper. The only thing that can stop the show is you.

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

You seem to confirm his findings whole-sale. I don't.
On my PCs the mtime remains unmodified. It's a weird
thing if it happens under normal circumstances, like
when someone else logs in on a computer and causes the
changes in ctime even though he didn't changed or 
saved anything to all appearance. But if it only 
happens when you fake the identity from within the
Office programs, well, I wouldn't bother really.

Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!

More information about the samba mailing list