Proposed patch: allow user to disable lockfile creation

Proposed patch: allow user to disable lockfile creation

[Dave Abrahams]

[-- Attachment #1: Type: text/plain, Size: 261 bytes --]


Hi,

Those symlinks that emacs creates to help avoid collisions between users
editing simultaneously cause me lots of pain and no gain, so I propose
the enclosed patch that allows me to disable the feature.

I hereby place these changes in the public domain.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-a-customizable-option-that-disables-lockfile-cre.patch --]
[-- Type: text/x-patch, Size: 3431 bytes --]

From e79326938de1c2567ac2ab1cac2fea91482a59e7 Mon Sep 17 00:00:00 2001
From: Dave Abrahams <dave@boostpro.com>
Date: Tue, 26 Jul 2011 22:32:13 -0400
Subject: [PATCH] Add a customizable option that disables lockfile creation

---
 ChangeLog            |    4 ++++
 doc/emacs/files.texi |    9 +++++----
 lisp/cus-start.el    |    1 +
 src/filelock.c       |    8 ++++++++
 4 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index e4a4754..87a3072 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2011-07-26  Dave Abrahams  <dave@boostpro.com>
+
+	* src/file_lock.c, lisp/cus-start.el: Add option to disable lockfile creation
+
 2011-06-19  Paul Eggert  <eggert@cs.ucla.edu>
 
 	* lib/unistd.in.h, m4/getloadavg.m4: Merge from gnulib.
diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi
index 793a11e..3f94741 100644
--- a/doc/emacs/files.texi
+++ b/doc/emacs/files.texi
@@ -761,16 +761,17 @@ to change the file, and issues an immediate warning.  On all systems,
 Emacs checks when you save the file, and warns if you are about to
 overwrite another user's changes.  You can prevent loss of the other
 user's work by taking the proper corrective action instead of saving the
-file.
+file.  
 
 @findex ask-user-about-lock
 @cindex locking files
   When you make the first modification in an Emacs buffer that is
 visiting a file, Emacs records that the file is @dfn{locked} by you.
 (It does this by creating a specially-named symbolic link in the same
-directory.)  Emacs removes the lock when you save the changes.  The
-idea is that the file is locked whenever an Emacs buffer visiting it
-has unsaved changes.
+directory.  You can disable this behavior by setting the variable
+@code{create-lockfiles} to @code{nil}).  Emacs removes the lock when
+you save the changes.  The idea is that the file is locked whenever an
+Emacs buffer visiting it has unsaved changes.
 
 @cindex collision
   If you begin to modify the buffer while the visited file is locked by
diff --git a/lisp/cus-start.el b/lisp/cus-start.el
index 389716b..1d8c908 100644
--- a/lisp/cus-start.el
+++ b/lisp/cus-start.el
@@ -183,6 +183,7 @@ Leaving \"Default\" unchecked is equivalent with specifying a default of
              (delete-by-moving-to-trash auto-save boolean "23.1")
 	     (auto-save-visited-file-name auto-save boolean)
 	     ;; filelock.c
+             (create-lockfiles files boolean)
 	     (temporary-file-directory
 	      ;; Darwin section added 24.1, does not seem worth :version bump.
 	      files directory nil
diff --git a/src/filelock.c b/src/filelock.c
index 13b27c7..8078a74 100644
--- a/src/filelock.c
+++ b/src/filelock.c
@@ -541,6 +541,10 @@ lock_file (Lisp_Object fn)
   lock_info_type lock_info;
   struct gcpro gcpro1;
 
+  /* Don't do locking if the user has opted out.  */
+  if (! Vcreate_lockfiles)
+    return;
+
   /* Don't do locking while dumping Emacs.
      Uncompressing wtmp files uses call-process, which does not work
      in an uninitialized Emacs.  */
@@ -709,6 +713,10 @@ syms_of_filelock (void)
 	       doc: /* The directory for writing temporary files.  */);
   Vtemporary_file_directory = Qnil;
 
+  DEFVAR_BOOL ("create-lockfiles", Vcreate_lockfiles,
+	       doc: /* Non-nil means use lockfiles to avoid editing collisions.  */);
+  Vcreate_lockfiles = 1;
+
 #ifdef CLASH_DETECTION
   defsubr (&Sunlock_buffer);
   defsubr (&Slock_buffer);
-- 
1.7.3.4


[-- Attachment #3: Type: text/plain, Size: 64 bytes --]



-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Proposed patch: allow user to disable lockfile creation

[Andreas Schwab]

Dave Abrahams <dave@boostpro.com> writes:

> Those symlinks that emacs creates to help avoid collisions between users
> editing simultaneously cause me lots of pain and no gain

Can you expand?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Proposed patch: allow user to disable lockfile creation

[Dave Abrahams]

on Wed Jul 27 2011, Andreas Schwab <schwab-AT-linux-m68k.org> wrote:

> Dave Abrahams <dave@boostpro.com> writes:
>
>> Those symlinks that emacs creates to help avoid collisions between users
>> editing simultaneously cause me lots of pain and no gain
>
> Can you expand?

Sure; for example, I have various tools that crawl the filesystem
looking for specially-named files, and when they operate on these
partially-complete files, it causes random trouble.  Sometimes it's
visible trouble, but sometimes it isn't (and invisible trouble is
worse).  Plus, they're annoying and distracting to look at in dired
buffers and the like.

On the other hand, I never collaboratively edit the same file as someone
else, and I use global-auto-revert-mode so that if I'm doing it in two
different emacs sessions, they stay in synch or I'm warned.

For me, the lockfiles offer no benefits and significant drawbacks.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Proposed patch: allow user to disable lockfile creation

[John Wiegley]

Dave Abrahams <dave@boostpro.com> writes:

> On the other hand, I never collaboratively edit the same file as someone
> else, and I use global-auto-revert-mode so that if I'm doing it in two
> different emacs sessions, they stay in synch or I'm warned.
>
> For me, the lockfiles offer no benefits and significant drawbacks.

I concur.  This is an annonying feature which has never once made any
difference to me.  I've been wanting a way to disable it for months now.

John

Re: Proposed patch: allow user to disable lockfile creation

[Stephen J. Turnbull]

John Wiegley writes:

 > I concur.  This is an annonying feature which has never once made
 > any difference to me.  I've been wanting a way to disable it for
 > months now.

XEmacs experience also is that users want to be able to disable this.
We have a variable `inhibit-clash-detection' for the purpose.

Re: Proposed patch: allow user to disable lockfile creation

[Richard Stallman]

    We have a variable `inhibit-clash-detection' for the purpose.

I wonder if it is possible to determine automatically the best value
for it.  To have multiple users on a machine requires serial terminals
or services that allow remote login.  My laptop has neither, so it is
impossible to have multiple users on it at once.

Maybe NFS provides a way to have multiple people editing in one file system.
It is possible to determine whether NFS is in use.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Proposed patch: allow user to disable lockfile creation

[Lennart Borgman]

On Thu, Jul 28, 2011 at 18:46, Richard Stallman <rms@gnu.org> wrote:
>    We have a variable `inhibit-clash-detection' for the purpose.
>
> I wonder if it is possible to determine automatically the best value
> for it.  To have multiple users on a machine requires serial terminals
> or services that allow remote login.  My laptop has neither, so it is
> impossible to have multiple users on it at once.

Is not the default today to have single users machines? And in other
cases have accounts setups so that clashes will not occur.

So isn't it better do avoid clash detection by default?

Re: Proposed patch: allow user to disable lockfile creation

[chad]

On Jul 28, 2011, at 9:46 AM, Richard Stallman wrote:

> Maybe NFS provides a way to have multiple people editing in one file system.
> It is possible to determine whether NFS is in use.

There are many remote filesystems in use today, and the number is increasing as people work to develop better alternatives to DropBox.  I'd guess that SMB, DropBox, WebDAV, NFS, and AFS are the most commonly used, but that's just a guess. I gather that modern VCSs have cut down on the use of network filesystems somewhat.

Without the lockfile, does Emacs not detect that the file has changed out from under the buffer? That used to be sufficient for me, when I used networked file systems 90% of the time.

Hope that helps,
*Chad

Re: Proposed patch: allow user to disable lockfile creation

[Paul Eggert]

On 07/28/11 09:46, Richard Stallman wrote:
> Maybe NFS provides a way to have multiple people editing in one file system.
> It is possible to determine whether NFS is in use.

These days, advisory file locks (fcntl with F_GETLK and F_SETLK) should be
reliable enough over NFS (and on local file systems) on practical GNU and
GNU-like machines, and should be able to do everything that Emacs's symlink
lock files do.  (This wasn't true way back when the symlink scheme was
originally introduced.)  If we used advisory file locks, I daresay we
could get rid of those symlinks.

Re: Proposed patch: allow user to disable lockfile creation

[Evil Boris]

Dave Abrahams <dave@boostpro.com> writes:

> Those symlinks that emacs creates to help avoid collisions between users
> editing simultaneously cause me lots of pain and no gain, so I propose
> the enclosed patch that allows me to disable the feature.

No one has brought this up yet: in my use case files are very rarely
edited by multiple users, but they are often edited by multiple
simultaneous instances of emacs; sometimes by multiple versions of
emacs.  I have been saved by the locking mechanism more than once.  Not
sure how crucial symlinks are to the implementation of those.  
Please do not remove the feature altogether.

Re: Proposed patch: allow user to disable lockfile creation

[Richard Stallman]

    Is not the default today to have single users machines? And in other
    cases have accounts setups so that clashes will not occur.

Most machines today are single users, but I don't follow the second
part.  What do you mean by "account setups"?

Normally, in a multi-user machine, people cooperate and there are some
files that various people might edit.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Proposed patch: allow user to disable lockfile creation

[Richard Stallman]

    There are many remote filesystems in use today, and the number is
    increasing as people work to develop better alternatives to
    DropBox.  I'd guess that SMB, DropBox, WebDAV, NFS, and AFS are
    the most commonly used, but that's just a guess.

Do they all show up in the output of `mount'?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Proposed patch: allow user to disable lockfile creation

[Tim Cross]

On Fri, Jul 29, 2011 at 9:00 AM, Richard Stallman <rms@gnu.org> wrote:
>    Is not the default today to have single users machines? And in other
>    cases have accounts setups so that clashes will not occur.
>
> Most machines today are single users, but I don't follow the second
> part.  What do you mean by "account setups"?
>
> Normally, in a multi-user machine, people cooperate and there are some
> files that various people might edit.
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>  Use free telephony http://directory.fsf.org/category/tel/
>
>

Another common use case is single systems with multiple serial users
i.e. there is only ever one person actively using the system, but it
is used by multiple people. In the 'old days' you would have to log
out to allow another person to log in (via the same keyboard/monitor
etc). However, many systems now have a 'switch user' context, which
allows the desktop to switch to another user without the previous use
logging out. Potentially, this could have locking implications.

Yes, as far as I know, most of the remote file systems do have an
entry in the output of df, at least under GNU Linux. Another common
remote filesystem is sshfs, which uses the fuse utilities with ssh and
can be dynamically created by the user. While most remote filesystems
can are listed in df, not all of them have entries in fstab and the
list is or can be somewhat dynamic i.e. change during a user's
session.

It seems that the issue isn't really about conflict detection per se,
but rather how emacs implements it via symlinks. If the OS level file
locking has matured enough, it would certainly be something worth
looking at as I imagine it will allow emacs to perform such protection
'privately' and not put things in the filesystem which can impact on
other programs.  Personally, I've not found this an issue as the
symlinks that emacs uses are easy to recognize and most of the scripts
I use are ones I've written and told to ignore such links/directories.

Tim

Re: Proposed patch: allow user to disable lockfile creation

[Dave Abrahams]

on Thu Jul 28 2011, Tim Cross <theophilusx-AT-gmail.com> wrote:

> It seems that the issue isn't really about conflict detection per se,
> but rather how emacs implements it via symlinks. 

It's actually more than that.  The scheme is simultaneously
over-cautious and yet full of holes.  It's predicated on the idea that
everybody who might touch the file simultaneously is using Emacs, but
that's obviously a fallacy.  Any program that doesn't respect Emacs'
convention and look for the lock file (e.g. every command-line tool in
existence) will happily write the file even when I have a lock on it.
Furthermore, Emacs is perfectly capable of telling me when that has
happened before I save... at least it seems to work pretty darned
reliably.  So I think this feature made sense once upon a time but is
now just a vestigial flipper.

Am I missing something?  I could be.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Proposed patch: allow user to disable lockfile creation

[Stephen J. Turnbull]

Richard Stallman writes:

 >     We have a variable `inhibit-clash-detection' for the purpose.
 > 
 > I wonder if it is possible to determine automatically the best value
 > for it.

Yes.  It's a constant = t (ie, no clash detection) IMO. :-)

Seriously, for backward compatibility I have to say the answer is nil
(enable clash detection).  While I agree with the arguments that clash
detection is mostly useless and occasionally a nuisance, there may be
people who currently depend on it and might lose data if it were
turned off by default and they had to explicitly turn it back on.  The
people who dislike the feature will happily turn it off in .emacs I
suppose.

 > To have multiple users on a machine requires serial terminals or
 > services that allow remote login.  My laptop has neither, so it is
 > impossible to have multiple users on it at once.

"Nothing is impossible."

I believe you have a Linux kernel on your laptop?  Most likely it is
configured with multiple virtual terminals on console.  While only one
login can use the console at each instant of time, it's certainly
possible to have serial use while multiple users are logged in.

As others have pointed out, this feature is also provided by many GUI
systems, including both the GNOME and KDE desktop environments common
on GNU/Linux systems.

Re: Proposed patch: allow user to disable lockfile creation

[Richard Stallman]

    These days, advisory file locks (fcntl with F_GETLK and F_SETLK) should be
    reliable enough over NFS (and on local file systems) on practical GNU and
    GNU-like machines, and should be able to do everything that Emacs's symlink
    lock files do.  (This wasn't true way back when the symlink scheme was
    originally introduced.)  If we used advisory file locks, I daresay we
    could get rid of those symlinks.

That sounds nice.  If we can do the same job in a way that never
bothers anyone, let's.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Proposed patch: allow user to disable lockfile creation

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     These days, advisory file locks (fcntl with F_GETLK and F_SETLK) should be
>     reliable enough over NFS (and on local file systems) on practical GNU and
>     GNU-like machines, and should be able to do everything that Emacs's symlink
>     lock files do.  (This wasn't true way back when the symlink scheme was
>     originally introduced.)  If we used advisory file locks, I daresay we
>     could get rid of those symlinks.
>
> That sounds nice.  If we can do the same job in a way that never
> bothers anyone, let's.

One of the most annoying things most PDF previewers under Windows
exhibit is that they lock the file they are displaying, meaning that
compilations generating PDF files will fail.  The nice way to do this is
to just watch the file and try reloading on redisplay when it has
changed.

Any locking scheme should make sure that it does not interact with other
programs: quite often I start a compilation and continue editing the
file in question, making sure I don't save until the compilation has
finished.

This sort of workflow should continue to be possible.

-- 
David Kastrup

Re: Proposed patch: allow user to disable lockfile creation

[Richard Stallman]

    It's actually more than that.  The scheme is simultaneously
    over-cautious and yet full of holes.

So what?  It still does a very useful job, providing advance warning
about simultaneous editing in many cases.

      It's predicated on the idea that
    everybody who might touch the file simultaneously is using Emacs,

No such assumption is made, because Emacs does not depend on this
feature to function every time.

The advance warning feature functions if the other person uses Emacs.
That's better than nothing.

    Furthermore, Emacs is perfectly capable of telling me when that has
    happened before I save... at least it seems to work pretty darned
    reliably.

That is why the advance warning feature does not need to be 100%
dependable.  It is an added convenience.  It is convenient to get the
warning before you start editing, rather than only when you try to
save the file.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Proposed patch: allow user to disable lockfile creation

[Richard Stallman]

     However, many systems now have a 'switch user' context, which
    allows the desktop to switch to another user without the previous use
    logging out. Potentially, this could have locking implications.

That is true.

If clash detection were done with advisory locks, it might be so
painless that nobody would want to ever disable it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Proposed patch: allow user to disable lockfile creation

[Dave Abrahams]

on Fri Jul 29 2011, Richard Stallman <rms-AT-gnu.org> wrote:

>     It's actually more than that.  The scheme is simultaneously
>     over-cautious and yet full of holes.
>
> So what?  It still does a very useful job, providing advance warning
> about simultaneous editing in many cases.
>
>       It's predicated on the idea that
>     everybody who might touch the file simultaneously is using Emacs,
>
> No such assumption is made, because Emacs does not depend on this
> feature to function every time.
>
> The advance warning feature functions if the other person uses Emacs.
> That's better than nothing.
>
>     Furthermore, Emacs is perfectly capable of telling me when that has
>     happened before I save... at least it seems to work pretty darned
>     reliably.
>
> That is why the advance warning feature does not need to be 100%
> dependable.  It is an added convenience.  It is convenient to get the
> warning before you start editing, rather than only when you try to
> save the file.

I'm sure that depends on your perspective about what's convenient.  The
advance warning feature may be convenient for you, but for me (and
apparently I'm not alone) it's a nuisance.  My patch simply allows
people to turn this feature off if they have the same experience as I
do.  Is there some reason it can't be accepted?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Proposed patch: allow user to disable lockfile creation

[Richard Stallman]

    Any locking scheme should make sure that it does not interact with other
    programs: quite often I start a compilation and continue editing the
    file in question, making sure I don't save until the compilation has
    finished.

If Emacs uses an advisory lock, and the PDF viewer does not use one,
will that give the desired result?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Proposed patch: allow user to disable lockfile creation

[Eli Zaretskii]

> From: Dave Abrahams <dave@boostpro.com>
> Date: Fri, 29 Jul 2011 23:29:38 -0400
> Cc: johnw@newartisans.com, theophilusx@gmail.com, lennart.borgman@gmail.com,
> 	emacs-devel@gnu.org, schwab@linux-m68k.org, stephen@xemacs.org
> 
> I'm sure that depends on your perspective about what's convenient.  The
> advance warning feature may be convenient for you, but for me (and
> apparently I'm not alone) it's a nuisance.  My patch simply allows
> people to turn this feature off if they have the same experience as I
> do.  Is there some reason it can't be accepted?

You can always disable this feature by removing the CLASH_DETECTION
macro definition on the appropriate header file in src/s/, can't you?

Re: Proposed patch: allow user to disable lockfile creation

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     Any locking scheme should make sure that it does not interact with other
>     programs: quite often I start a compilation and continue editing the
>     file in question, making sure I don't save until the compilation has
>     finished.
>
> If Emacs uses an advisory lock, and the PDF viewer does not use one,
> will that give the desired result?

The PDF viewer was an example for an application that causes grief by
locking in connection with compilation processes.  One does not need
Emacs to have, say, a LaTeX compilation fail because a PDF viewer blocks
the resulting file.

I was trying to say that we should try to keep Emacs from being as
annoying in program/file interaction as those viewers are.

I have no personal experience with advisory locking, so I can't answer
your question.  Maybe somebody else can?

-- 
David Kastrup

Re: Proposed patch: allow user to disable lockfile creation

[Dave Abrahams]

on Sat Jul 30 2011, Eli Zaretskii <eliz-AT-gnu.org> wrote:

>> From: Dave Abrahams <dave@boostpro.com>
>> Date: Fri, 29 Jul 2011 23:29:38 -0400
>> Cc: johnw@newartisans.com, theophilusx@gmail.com, lennart.borgman@gmail.com,
>> 	emacs-devel@gnu.org, schwab@linux-m68k.org, stephen@xemacs.org
>> 
>> I'm sure that depends on your perspective about what's convenient.  The
>> advance warning feature may be convenient for you, but for me (and
>> apparently I'm not alone) it's a nuisance.  My patch simply allows
>> people to turn this feature off if they have the same experience as I
>> do.  Is there some reason it can't be accepted?
>
> You can always disable this feature by removing the CLASH_DETECTION
> macro definition on the appropriate header file in src/s/, can't you?

Sure, if I want to maintain my own fork, rebuild emacs at every new
release, and not benefit any of the other people who are bothered by
this feature.  I was really hoping to avoid all of those outcomes.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Proposed patch: allow user to disable lockfile creation

[Dave Abrahams]

on Fri Jul 29 2011, Richard Stallman <rms-AT-gnu.org> wrote:

>      However, many systems now have a 'switch user' context, which
>     allows the desktop to switch to another user without the previous use
>     logging out. Potentially, this could have locking implications.
>
> That is true.
>
> If clash detection were done with advisory locks, it might be so
> painless that nobody would want to ever disable it.

Might be.  I'm all for any change that requires no additional user
options.  We might discover after releasing it that we still need the
option, but that kind of change would solve my immediate issue without
making things worse.  Unfortunately, it's not a change I know how to
make, so someone else would need to supply the patch.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

Re: Proposed patch: allow user to disable lockfile creation

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 627 bytes --]

On 7/26/11 7:42 PM, Dave Abrahams wrote:
> Those symlinks that emacs creates to help avoid collisions between users
> editing simultaneously cause me lots of pain and no gain, so I propose
> the enclosed patch that allows me to disable the feature.

Count me among those who would like to disable clash detection.  I would prefer,
however, that instead of a simple disabling mechanism we provide a generic Lisp
hook, i.e., a new lock-file-function variable, which could be set to 'ignore.
This way, we provide mechanism, not policy, at the C level, and allow more
experimentation with alternate locking strategies.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Proposed patch: allow user to disable lockfile creation

[Richard Stallman]

    > That is why the advance warning feature does not need to be 100%
    > dependable.  It is an added convenience.  It is convenient to get the
    > warning before you start editing, rather than only when you try to
    > save the file.

    I'm sure that depends on your perspective about what's convenient.  The
    advance warning feature may be convenient for you, but for me (and
    apparently I'm not alone) it's a nuisance.

We are miscommunicating.  I am not arguing against the feature you
requested.  I don't see anything bad about it.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Proposed patch: allow user to disable lockfile creation

[Richard Stallman]

    Count me among those who would like to disable clash detection.

We should try to improve clash detection by using advisory locks.  If
that makes it so smooth that it doesn't bother anyone, we will be
finished with it.  If some still find it annoying, then let's add some
sort of feature to disable it.


-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Proposed patch: allow user to disable lockfile creation

[Tim Cross]

On Fri, Jul 29, 2011 at 10:51 AM, Dave Abrahams <dave@boostpro.com> wrote:
>
> on Thu Jul 28 2011, Tim Cross <theophilusx-AT-gmail.com> wrote:
>
>> It seems that the issue isn't really about conflict detection per se,
>> but rather how emacs implements it via symlinks.
>
> It's actually more than that.  The scheme is simultaneously
> over-cautious and yet full of holes.  It's predicated on the idea that
> everybody who might touch the file simultaneously is using Emacs, but
> that's obviously a fallacy.  Any program that doesn't respect Emacs'
> convention and look for the lock file (e.g. every command-line tool in
> existence) will happily write the file even when I have a lock on it.
> Furthermore, Emacs is perfectly capable of telling me when that has
> happened before I save... at least it seems to work pretty darned
> reliably.  So I think this feature made sense once upon a time but is
> now just a vestigial flipper.
>
> Am I missing something?  I could be.
>

Sorry, a bit confused now. Are you saying there is no need for emacs
to do any form of conflict resolution at all? From what others have
posted, my impression was that the current implementation was a
problem and therefore, there was a request to be able to turn it off.
My feeling was that conflict resolution is not a bad thing in itself
and if properly implemented, would achieve its desired goal without
getting in the way and therefore, without the need to be able to turn
it on or off. Hence my suggestion to look at OS provided facilities,
which may have matured to the point they could be used instead of what
is seen by some, as emacs' old and outdated approach.

However, I will also say I probably don't understand the problem. I've
been using emacs daily since the mid 90's and have yet to encounter a
problem with this aspect of the software, so I don't quite understand
why it is even an issue, apart from possible aesthetic reasons, which
are fine, but difficult to get consensus on.

Tim

Re: Proposed patch: allow user to disable lockfile creation

[Tim Cross]

On Sun, Jul 31, 2011 at 4:12 AM, Richard Stallman <rms@gnu.org> wrote:
>    Count me among those who would like to disable clash detection.
>
> We should try to improve clash detection by using advisory locks.  If
> that makes it so smooth that it doesn't bother anyone, we will be
> finished with it.  If some still find it annoying, then let's add some
> sort of feature to disable it.
>
>
> --
> Dr Richard Stallman
> President, Free Software Foundation
> 51 Franklin St
> Boston MA 02110
> USA
> www.fsf.org  www.gnu.org
> Skype: No way! That's nonfree (freedom-denying) software.
>  Use free telephony http://directory.fsf.org/category/tel/
>
>

+1