After upgrading to 3.0.11, we cannot use our Shared Workbooks in MS Excel 2000 SP3. If the owner of the file opens the .xls workbook, it works. If other user (UNIX permissions are OK) opens, the file is opened, but an error is displayed: "File is locked. In order to save changes to the file, you can either close the file before making any changes and then re-open it, use Save As (File menu) to save the file using another file name, or turn off Shared Workbooks and then save the file." After pressing OK, I cannot even save to the same filename. If I uncheck the "Shared file" checkbox, no error occurs.
jeremy, can you bump this one up on your list. We've got multiple reports on it. Current thread can be found at http://lists.samba.org/archive/samba/2005-March/101686.html
Hopefully helpful: Full text of error message: "File is locked. In order to save changes to the file, you can either close the file before making any changes and then re-open it, use Save As (File menu) to save the file using another filename, or turn off Shared Workbooks and then save the file." Installing the "Custom Error Messages" add-in does not yield a "Web Info" button on that error message.
Note from the list. Here is a MS-knowledgebase article on the problem : http://support.microsoft.com/default.aspx/kb/324491? Jeremy.
Created attachment 1022 [details] Proposed patch. Ok, please give this a try (it's checked into SVN also). Thanks, Jeremy.
I've realised that the semantics of this patch aren't quite right - I need to save the pending_modtime only as long as the fsp that received the change time request is open - the current patch keeps it around for as long as any file open on the same dev/ino pair is open. I need to add a "pending_modtime_owner" field to the fsp struct and keep track of who was sent the time change request. Look for this fix tomorrow (3/10/2005 US Pacific time). The current patch should work well enough to test against though. Jeremy.
Ok, the modified fix is in the SAMBA_3_0 and HEAD SVN code. I'm testing now with Office 2003 and so will wait for confirmation from a customer before closing - but I think this may be fixed now. Jeremy.
I have tested with the new 3.0.12 Debian Binary packages from the Samba repository, and with NO success. The "user" behaviour is the same, the same error messages come up.
We are getting the same thing on our server running 3.0.12 compiled from the tarball. Only the user that is the owner of the file is able to work with a shared workbook. . Everyone else gets the "File is locked" message even though we are all members of the group that owns the file.
I've just tried and cannot reproduce this using Office 2003 Professional version 11.5612.5606 on XP and version 11.6355.6408 on Win2K3. Is it specific to Office 2000 ? Can you reproduce it on Office 2003 ? I'm trying to track down if this is a Office version specific bug, in which case I'll downgrade my version of Office to test. Jeremy.
It's happening for us with Excel 2003 (11.6355.6360) SP1 on Windows XP SP2.
Created attachment 1113 [details] Proposed patch. Ok, I have a working theory for this. It concerns ACLs and what happens when excel wants to update the filetime on a file the user doesn't own. Normally you just set the "dos filetime" parameter to allow this (this causes a timestamp to be updated on a file if you can write to it - normally POSIX only allows this if you're the owner). I've realised the codepath here doesn't check ACL semantics. This is a bug we've had since we introduced ACLs a long time ago but only now seems to have been triggered. Here is a patch to the just released 3.0.13 that causes ACL entries to be properly checked when "dos filetime= True" has been set. Please try this on top of 3.0.13 and let me know if it fixes the issues.
Actually, setting dos filetime = true solved the problem (I thought I had tried that before, but was it turns out I was editing the wrong conf file.) If I had known that Excel needs to modify the time on shared files, I would have looked more closely at it before commenting here. Sorry for the confusion, but hopefully it will solve the other user's problem.
Thanks - I'm closing this one out. Jeremy.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.