Bug 1601 - Excel, PowerPoint files timestamp is always updated even when the file is not saved on the samba share
Excel, PowerPoint files timestamp is always updated even when the file is not...
Status: CLOSED FIXED
Product: Samba 3.0
Classification: Unclassified
Component: File Services
3.0.4
x86 Windows 2000
: P3 critical
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-11 01:42 UTC by Suleyman Gultekin
Modified: 2013-03-12 21:33 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Suleyman Gultekin 2004-08-11 01:42:24 UTC
We noticed a common problem to all OS & Office versions in our company 
regarding the file server we use.
Every time we open an Excel or Powerpoint document on the file server (Linux 
Samba server) the timestamp of the document is updated with the open timestamp 
even if we don't save the document!
This occur only when we open an Excel or Powerpoint document on the samba 
share. The problem doesn't occur on the local disk of any client. And this is 
regardless the client's OS & Office version.

Thank you for any help.

Best regards,

Suleyman Gultekin
Platform info:
==============
Samba server
HW : Intel Dual Xeon 3 GHz CPU
OS : RedHat Advanced Server 2.4.21-9.0.1.ELsmp

Name        : samba                         Relocations: (not relocatable)
Version     : 3.0.4                         Vendor: Red Hat, Inc.
Release     : 6.3E                          Build Date: Tue Jul 20 15:44:09 2004
Install Date: Tue Aug 10 17:52:44 2004      Build Host: tweety.build.redhat.com
Group       : System Environment/Daemons    Source RPM: samba-3.0.4-6.3E.src.rpm
Size        : 25693830                         License: GNU GPL Version 2
Signature   : DSA/SHA1, Wed Jul 21 04:59:53 2004, Key ID 219180cddb42a60e
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.samba.org/
Summary     : The Samba SMB server.

Clients:
========
Windows 2000 Pro SP4 (Intel P4)
Win XP SP1 (Intel P4)
Office 2000 - 2002 - 2003
Comment 1 Maximiliano Pin 2004-09-02 01:30:36 UTC
In our company we are having the same problem. Actually, excel and ppoint files
are modified whenever they are open (because they have the lock embedded, in
contrast to word files), but office restores their modification time when they
are closed. For some reason, when a file is in a samba server, the modification
time cannot be restored when the file is closed.

This is not nice because we used to find very useful to trust modification time
of these files.

Samba version: 3.0.5 (on Debian)
Clients: Windows 2000

Regards,
Maximiliano Pin
Comment 2 Willem Meints 2004-11-18 07:32:24 UTC
In our company we are having the same problem. Actually, excel and powerpoint 
filesare modified whenever they are open 

This is not nice because we used to find very useful to sort on the date of an 
file.
Comment 3 Marc Kaplan 2004-11-18 14:29:53 UTC
I do see that the files get their timestamp changed when it is opened by Excel,
but I also see it getting changed back after the file is closed. Could somebody
perhaps attach a network trace illustrating this problem?

          -Marc
Comment 4 Maximiliano Pin 2004-11-19 02:48:27 UTC
I discovered more information about this. The problem only happens when the user
who opens the file is different from the user who created the file. I'm talking
about UNIX users. In our configuration, we have two users, user1 and user2, and
many windows machines connecting with those users. Both are in the same group,
group1. And masks in smb.conf are such than files created are like these:
-rwxrw----  1 user1  group1  13824 Nov 19 09:48 proof.xls*
-rwxrw----  1 user2  group1  11776 Nov 19 10:01 proof2.xls*

If someone using "user2" opens "proof.xls", the problem appears. But, if I make
"chown user2 proof.xls" the problem disappears!! And vice-versa. I tried
changing the modification time of proof.xls being user2 (with touch -t), and
it's impossible! (remember user2 is in group1, and has write access to the file)

user2@server$ touch proof.xls
(No problem with this.)
user2@server$ touch -t "11191024" proof.xls
touch: setting times of `proof2.xls': Operation not permitted

This could be linux-specific. This bug seems to have no easy solution, maybe
smbd could treat modification time changes as root, instead of switching to the
correct user, in this special request.
Comment 5 Willem Meints 2004-11-23 04:56:11 UTC
> This could be linux-specific. This bug seems to have no easy solution, maybe
> smbd could treat modification time changes as root, instead of switching to 
the
> correct user, in this special request.

Im sorry for my english.
Maybe it is possible to give an user root rights and see if the problem is 
still there. Can someone try this? 


Comment 6 Willem Meints 2004-11-26 02:52:50 UTC
http://lists.samba.org/archive/samba/2004-May/086562.html

See this link.
Comment 7 Joshua Buysse 2004-12-29 09:11:29 UTC
> This could be linux-specific. This bug seems to have no easy solution, maybe
> smbd could treat modification time changes as root, instead of switching to the
> correct user, in this special request.

This is not linux-specific; I'm seeing the same problem with Solaris and the current release of Samba 
(the CSW builds from http://blastwave.org/).
Comment 8 Gerald (Jerry) Carter 2005-02-08 21:20:43 UTC
please retest with the 3.0.11 release.  It is possible that 
jra's sticky mtime fix tookcare of this.
Comment 9 Gerald (Jerry) Carter 2005-08-24 10:20:43 UTC
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
Comment 10 roland 2013-03-12 21:27:16 UTC
oh - this "bug" is not even samba specific - it is excel specific, as excel does dirty tricks. when opening for reading, excel stores the username in it and on closing, it restores the original timestamp when the file had not been changed in excel. the file on disk indeed IS being changed - as the user last accessing it is saved in the file - but robocopy or rsync will never know if they do not binary compare with the target file to be "synced". came across this during a fileserver migration.....
don't know if recent excel versions still do this....
Comment 11 roland 2013-03-12 21:33:20 UTC
apparently, recent excel still does - and m$ even managed to introduce another bug with this ;)

http://support.microsoft.com/kb/948355/en-us
http://support.microsoft.com/kb/826741