GNOME Bugzilla – Bug 334024
File Locking
Last modified: 2018-03-25 22:42:58 UTC
Prevent concurrent editing of a workbook using hidden lockfiles. Externally locked workbooks may be viewed and edited, but not saved unless the name is changed.
Created attachment 60994 [details] [review] [patch for 1.6.2] that adds dot-file locking This patch adds locking capabilities to gnumeric version 1.6.2, preventing modification of the same workbook by multiple users or program instances. The mechanism used is creation of hidden (on UNIX at least) lock files (lock filename syntax: DOT <workbookname> DOT lock). A lock file is created for each named workbook that is opened. The lock file contains the ascii string "user@host (uid xxx, pid xxx)" to identify the holder of the lock. If a locked workbook is opened by gnumeric, the user will be informed of the lock and be told of the current lock holder (and some explanation of why the file might be locked). The SAVE functionality will also be disabled for workbooks where the lock is held by an external party. To save data, the user must use SAVE-AS. Attempts are made to discover failures when they occur (such as a lockfile being deleted by a crafty user), and to tolerate them when possible. Some testing to verify that locking works in the obvious foreseeable cases was performed.
Created attachment 63379 [details] [review] [patch for 1.6.2] that adds dot-file locking Includes bug fixes and cleanups wrt previous patch.
*** Bug 155970 has been marked as a duplicate of this bug. ***
*** Bug 127144 has been marked as a duplicate of this bug. ***
*** Bug 660488 has been marked as a duplicate of this bug. ***
*** Bug 697347 has been marked as a duplicate of this bug. ***
We will now verify that nothing has changed the file underneath us when we save. That isn't the approach taken in this bug report, but it will prevent the accidental overwrite of someone else's work. This problem has been fixed in our software repository. The fix will go into the next software release. Once that release is available, you may want to check for a software upgrade provided by your Linux distribution.
Presumably checking for changes leaves a race condition in place if two users are editing the spreadsheet at the same time. Actual locking seems more robust; why not use real locks? Regards, Andy
I don't see a problem with two users working on the same document until and unless they same on top of each others. That last thing is now prevented. Also, we're talking spreadsheets here with a multitude of different editors. Localc wouldn't respect Gnumeric locks and who knows what Excel does?