samba - Aug 2003 - Samba vs. Windows : significant difference in timestamp handling ?

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

f.pospischil@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.

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

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

|> 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!
http://login.mail.lycos.com/r/referral?aid=27005

From:        "Dragan Krnic" <dkrnic@lycos.com>        12.08.2003
20:31
Please respond to dkrnic
To:     mdonovan@edwtech.com
cc:     samba@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

>|> 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".
Oops! What do you mean "different users with the same
name"? This is new to me. Unless you mean different
people using the same userID, that of the Administrator
nothing less, in which case they are not different 
people from the point of view of a dumb server.

The show-stopper for your migration might be the lax 
rules of engagement where everyone logs in as 
Administrator and then fakes identities by using 
obscure Office sudo's.

Before you migrate, you should perhaps wean your users
off such practices. My users are people like HansBeck
and JuergenWiesenthal. Where I see a share used by root
it better be me lest the hell breaks loose.
>|> 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 ...
Of course. The first test without restarting PPT shew
no problem. Only after restarting PPT did I find out
that ctime changes. By the way ctime is inode state
change time.
>> 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.
Yes, but should you store the file before exitting it
would then be owned by you. How MS tools work is not
quite transparent. There are many bugs there that
will never be detected because there is no peer review
of their work. Perhaps PPT thinks that it should 
revert the ownership to original owner and generates
an inode state change which doesn't change anything
but the ctime.
>|> 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 ...)
Well the purpose of atime is to record the access time,
even when nothing chages. If the access time remains
the same after viewing a ppt document, then there's
something wrong, but you can't set such high standards
of consistency on MS, can you?
> 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 ...
Again this can't be true or it's a bug. When a file is
copied mtime should remain the same. We can start a
religious war whether atime should change but I'm not
worried either way. However ctime should reflect the 
last inode state change of the new file not the last 
inode state change of the original file. What's 
perhaps confusing you, is that MS has a 4th timestamp 
in their scheme, which can't be aped by samba short of 
using EAs, which is caled create time. I'm not sure 
what it means exactly but it is not the same as inode 
state change time, ctime.
>> 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.
I surely spake of 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 !
Fine. Use reiserfs and don't worry about ctime.


____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

>> Oops! What do you mean "different users with the 
>> same name"? This is new to me. ...
>
> Have you ever noticed the options Dialog in any 
> Office application ? (Something like 
> Tools->options->general(PPT) or Userinfo(Word)
> You should tell MS Office who you are to enable 
> things like Revisions and Comments and finally 
> the "Document is in use by Mr. Dragan Krnic" message.
> User ID-names are not very helpful by default. (Some 
> Admins use partly numeric ID´s with employeenumbers 
> from the HR department ...) But this could also be a 
> relict of ancient times, when Windows was a single
> user OS where properties like realname were not 
> present. (As the whole usermanagement ...)
It defaults to the presently logged in user, 
DraganKrnic in my case. Some add titles like Sir, or
Dr. but I can't say what happens when they log in on
a client other than their own. My default name follows
me everywhere in the domain. It may be different in
the case of a TE/TS. I don't know.
>> The show-stopper for your migration might be the lax
>> rules of engagement where everyone logs in as
>> Administrator and then fakes identities by using
>> obscure Office sudo's.
>>
>> Before you migrate, you should perhaps wean your 
>> users off such practices....
>
>Have you read my posting ?
I thought I did.
> Noone but the Administrator logs in as Administrator.
Sorry for this misunderstanding.
> Administrator is the default Office-user-name that 
> is written to the "DEFAULT_USER" registry hive when 
> MS Office is installed in Terminal Server mode. 
... because it is usually the Administrator who 
installs it...
> Values of this hive will then be copied to new users 
> to give them proper settings for such irrelevant 
> things like "Program Path", "Group Templates", 
> Add-Ins etc. I bet the changed timestamp thing will 
> not occur in your environment, because not a single 
> user has filled in the name property, so there is no
> "multi-user-office-usage" from the dumb Server´s 
> point of view.
Rather because there are no TE's here. Almost everyone 
has his own client and there's a pool of a dozen
clients which anybody can use on 1st-come-1st-served
basis. These people are absolutely dependent on such
details as time-stamping, ownership, group-ownership
(quotas), access rights (ACLs), and they didn't need 
to do anything extra to make it work. 

Terminal servers are not my kind of beer. They do seem 
to introduce another layer of complexity to an already 
fsck'd up os. Thin clients is a buzzword like RAID. 
In the mouth of salespeople it sounds like you are
going to make a nice saving if instead of buying a
six-pack of state-of-art PCs you buy a dual or quad
server and 5 worthless/diskless PCs. Just like in case
of RAIDs, you end up paying more money for less power
and a tricky system requiring a service contract to
work.

Of course, there are situations where a terminal server
is better than a VNC. We are considering TS model for 
a number of very remote worker clients. But we are 
also considering setting them up as virtual hosts 
under Linux and using X11 emulation to access them. 
The latter has many performance advantages in addition 
to many times lower investment price. The only 
argument in favour of TS model is that it is MS and 
all of the remote stuff are MSCEs.
>> >> 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.
>
>> ... Perhaps PPT thinks that it should
>> revert the ownership to original owner and generates
>> an inode state change which doesn't change anything
>> but the ctime.
>
> Perhaps the moon falls from the sky tonight ...
We'll never know unless you do some observations. It
was an admittedly uneducated guess, but not so far 
off as the moon event.
> AFAIK, the new owner results from the fakt that the 
> temporary file (that is naturally owned by the one 
> who accesses the original file) is copied to the 
> original location and really overwrites the original 
> file with the current user as owner and new creation 
> time. That´s ok for me. This can be handled by 
> intelligent user rights management by groups and
> ACLs. Not the topic here.
Rather, the original file is deleted and the new one
is renamed after the original. But it really doesn't
matter mostly.
>>...but you can't set such high standards
>> of consistency on MS, can you?
>
>I could -but i don´t. Because i´m not new to IT ...
That's a realistic attitude. Samba is in many ways
better software but it's not bug-4-bug compatible
with MS. Close but not quite.
>> Fine. Use reiserfs and don't worry about ctime.
>
>But reiserfs doesn´t support ACLs. Does it?
Oh yes, it does. Big way.


____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

>>|> 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.
IMPORTANT UPDATE:
My above experience was made as DOMAIN\Administrator.
However, I tested it with several ordinary users and
by all of them only the access time is affected. The
ctime and mtime remain the same, as long as no change
is committed to the disk.

It is strange enough that Administrator's access 
should also change the ctime but what you report about
mtime being changed is beyond the pale. I suspect ext3
is the problem. I heard some people losing all of 
their data on ext3-formatted disks. Stay away from it.



____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

>>>|> 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.
>
> IMPORTANT UPDATE:
> My above experience was made as DOMAIN\Administrator.
> However, I tested it with several ordinary users and
> by all of them only the access time is affected. The
> ctime and mtime remain the same, as long as no change
> is committed to the disk.
ONE MORE:
The test PPT file I used as seen by Explorer after
viewing and closing it with faked identity:

File    Created           Modified          Accessed
ppt.ppt 12.08.2003 17:43  12.08.2003 17:43  15.08.2003 16:45

The same file seen with Linux command stat:

   # stat ppt.ppt 
     File: `ppt.ppt'
     Size: 8192 Blocks: 16 IO Block: 4096 regular file
   Device: 6801h/26625d Inode: 186323 Links: 1    
   Access: (0774/-rwxrwxr--) Uid:(0/root) Gid:(0/root)
   Access: 2003-08-15 16:45:38.000000000 +0100
   Modify: 2003-08-12 17:43:09.000000000 +0100
   Change: 2003-08-15 16:45:38.000000000 +0100

The ctime gets changed whenever atime changes!?
Windows shows mtime as both mtime and ctime.?!

Is it a bug or a feature? 


____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005

>> It is strange enough that Administrator's access 
>> should also change the ctime but what you report 
>> about mtime being changed is beyond the pale. I 
>> suspect ext3 is the problem.
>
> You can test this.  Just remount your ext3 partition 
> as ext2 and see if the problem persists.  The 
> formats are compatible.
>
> I haven't personally heard of any data loss problems 
> with ext3 since it went into the stable kernels.  
> It's probably not the best filesystem for file 
> server use (ReiserFS is much faster) but I don't 
> think people need to be afraid of it.
You're perfectly right, David. It was meant to be a
prank, but I lost a :-) copy/pasting it in hurry.



____________________________________________________________
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005