>|> 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 -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
