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

[f.pospischil at telenet-ag.de]

From:        "Dragan Krnic" <dkrnic at lycos.com>        12.08.2003 20:31
Please respond to dkrnic
To:     mdonovan at edwtech.com
cc:     samba at lists.samba.org
Subject:        Re: Samba vs. Windows : significant difference in timestamp handling ?



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

This is for your convenience when trying to reproduce this behavior.
Of course we do not change this option in normal business.
It´s only to make clear that it´s not somthing like 
User-Profile/registry/rights problems !
Powerpoint must be restartet again, after the change was made.Same session 
refers to user-session, not PPT-Session.
I mention this because I had the situation where different users with the 
same name (Administrator, which is the default setting in TSE 
environments)could not reproduce this behavior when looking at each 
other´s files.
So the important difference that makes the fuss is an access with a 
different username in the Office-related registry branch, not a different 
"userprofile".

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

restarted ppt ? see above ...

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

Does "belongs to him" mean that he became owner of the file ?
The owner (user and group) did not change. At no time. The file is (and 
was ever) owned by the creator.
The given examples did not document this, sorry.

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

Can you confirm this behavior ? (Even if it can´t be ...)
The access-time in Windows is not modified, when a file is copied.
PPT locks the file and creates a copy in the user´s local temp-folder, 
works on it and then (when sth. is changed) replaces the original file 
with some modifications to the timestamps. (e.g. preserve original 
creation time)
That´s what i observed, no evidence ...

|> 
|> Question 1:
|> Can somebody please confirm this behavior ?

>... never ran into any problems. Perhaps because we use 
>reiserfs ...

Might be a point ...
 
|> 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.

Ooops, have a closer look:
(excerpt from the samba-doc)
dos filetimes (S)
Under DOS and Windows, if a user can write to a file they can change the 
timestamp on it. Under POSIX semantics, only the owner of the file or root 
may change the timestamp. By default, Samba runs with POSIX semantics and 
refuses to change the timestamp on a file if the user smbd is acting on 
behalf of is not the file owner. Setting this option to yes allows DOS 
semantics and smbd will change the file timestamp as DOS requires.

You shurely speak about dos_filetime_resolution.

>... On my PCs the mtime remains unmodified. It's a weird
>thing if it happens under normal circumstances ...
>But if it only 
>happens when you fake the identity from within the
>Office programs, well, I wouldn't bother really.

I totally agree !


Thanks for your efforts an time spent so far.
Frank