After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 334024 - File Locking
File Locking
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: Main System
1.6.x
Other All
: Normal enhancement
: ---
Assigned To: Jody Goldberg
Jody Goldberg
: 127144 155970 660488 697347 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-03-09 13:59 UTC by Tammo Spalink
Modified: 2018-03-25 22:42 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
[patch for 1.6.2] that adds dot-file locking (20.68 KB, patch)
2006-03-09 18:55 UTC, Tammo Spalink
none Details | Review
[patch for 1.6.2] that adds dot-file locking (20.84 KB, patch)
2006-04-13 13:37 UTC, Tammo Spalink
none Details | Review

Description Tammo Spalink 2006-03-09 13:59:30 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.
Comment 1 Tammo Spalink 2006-03-09 18:55:22 UTC
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.
Comment 2 Tammo Spalink 2006-04-13 13:37:58 UTC
Created attachment 63379 [details] [review]
[patch for 1.6.2] that adds dot-file locking

Includes bug fixes and cleanups wrt previous patch.
Comment 3 Morten Welinder 2006-04-19 03:03:59 UTC
*** Bug 155970 has been marked as a duplicate of this bug. ***
Comment 4 Morten Welinder 2006-04-19 20:42:46 UTC
*** Bug 127144 has been marked as a duplicate of this bug. ***
Comment 5 Andreas J. Guelzow 2011-09-29 17:29:22 UTC
*** Bug 660488 has been marked as a duplicate of this bug. ***
Comment 6 Morten Welinder 2013-04-05 17:12:44 UTC
*** Bug 697347 has been marked as a duplicate of this bug. ***
Comment 7 Morten Welinder 2018-03-25 19:51:34 UTC
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.
Comment 8 Andrew Schorr 2018-03-25 20:08:28 UTC
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
Comment 9 Morten Welinder 2018-03-25 22:42:58 UTC
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?