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

[Dragan Krnic]

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