bug#18828: 24.4; Early collision warning when 'create-lockfiles' is set to nil

bug#18828: 24.4; Early collision warning when 'create-lockfiles' is set to nil

[Dani Moncayo]

Recipe:
0. emacs -Q
1. Eval: (setq create-lockfiles nil)
2. Visit some file
3. With another program, update the visited file.
4. Try to make some change to the buffer.

------------

Without step 1, Emacs does TRT, i.e., it detects that I'm trying to
make the first change to a buffer whose file has already changed since
it was visited, so it warns me with:

 foo changed on disk; really edit the buffer? (y, n, r or C-h)

But with step 1, Emacs doesn't warn me until I try to save the buffer;
then it shows me this:

  foo has changed since visited or saved.  Save anyway? (yes or no)

(BTW: the above message does not get archived in the *Messages*
buffer.  Why not?  I think it should, as with the first warning)

Well, I think that Emacs should warn me on step 4, regardles of
whether I did step 1 or not.

I set `create-lockfiles' to nil in my init file because I don't want
Emacs to create temporary files of any kind, but obviously I want to
be warned whenever I am about to change a buffer whose file has
changed on disk after it was last read by Emacs.

I observe this bug both with the last 24.4 release and with the trunk.

In GNU Emacs 24.4.1 (i686-pc-mingw32)
 of 2014-10-20 on LEG570
Windowing system distributor `Microsoft Corp.', version 6.3.9600
Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1252

-- 
Dani Moncayo

bug#18828: 24.4; Early collision warning when 'create-lockfiles' is set to nil

[Daniel Lopez]

I've noticed this too.

(setq create-lockfiles nil) seems to turn off both the creation of 
lockfiles (which are used to alert you if you start to modify a file 
which another Emacs session concurrently has open in a modified, unsaved 
state); and the feature of prompting you if you start to modify a file 
which has changed on disk from what is visible in the buffer since you 
opened or last reverted it.

I find myself wanting the latter feature but not the former. In 
particular, the latter feature will detect if the file contents have 
been changed by another application, whereas the lockfiles feature will 
only detect if the file is currently being edited by another instance of 
Emacs. So the 'create-lockfiles' variable should be limited to only 
control the former feature, and maybe there should be another setting 
for turning the latter feature on and off, though I wouldn't want to 
turn if off myself.

Daniel

bug#18828: 24.4; Early collision warning when 'create-lockfiles' is set to nil

[Dani Moncayo]

Ping?

-- 
Dani Moncayo   "looking forward to the fix for this bug"

bug#18828: 24.4; Early collision warning when 'create-lockfiles' is set to nil

[Glenn Morris]

Dani Moncayo wrote:

> Ping?

Don't set create-lockfiles to nil?
That's the traditional mechanism by which Emacs manages this stuff.
Making it work with that feature disabled is not a high priority.

bug#18828: 24.4; Early collision warning when 'create-lockfiles' is set to nil

[Dani Moncayo]

>> Ping?
>
> Don't set create-lockfiles to nil?
> That's the traditional mechanism by which Emacs manages this stuff.

Well, that's not what some users (like myself) may want.

I don't like those temporary files, specially on auto-sync
directories (e.g. dropbox, google drive, etc), for obvious
reasons.

> Making it work with that feature disabled is not a high priority.

Ok. Thanks.

-- 
Dani Moncayo

bug#18828: 24.4; Early collision warning when 'create-lockfiles' is set to nil

[Glenn Morris]

Dani Moncayo wrote:

>> Don't set create-lockfiles to nil?
>> That's the traditional mechanism by which Emacs manages this stuff.
>
> Well, that's not what some users (like myself) may want.

Can only fall back to "patches welcome" then. :(
Though sadly we cannot promise to apply patches in a timely fashion. :(

bug#18828: 24.4; Early collision warning when 'create-lockfiles' is set to nil

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Wed, 29 Apr 2015 11:57:30 -0400
> Cc: 18828@debbugs.gnu.org
> 
> Dani Moncayo wrote:
> 
> >> Don't set create-lockfiles to nil?
> >> That's the traditional mechanism by which Emacs manages this stuff.
> >
> > Well, that's not what some users (like myself) may want.
> 
> Can only fall back to "patches welcome" then. :(

Here you go (if no one objects, I will push this in a few days):

--- src/filelock.c~0	2015-01-26 14:45:50 +0200
+++ src/filelock.c	2015-04-29 13:46:42 +0300
@@ -669,10 +669,6 @@ lock_file (Lisp_Object fn)
   struct gcpro gcpro1;
   USE_SAFE_ALLOCA;
 
-  /* Don't do locking if the user has opted out.  */
-  if (! create_lockfiles)
-    return;
-
   /* Don't do locking while dumping Emacs.
      Uncompressing wtmp files uses call-process, which does not work
      in an uninitialized Emacs.  */
@@ -690,9 +686,6 @@ lock_file (Lisp_Object fn)
 #endif
   encoded_fn = ENCODE_FILE (fn);
 
-  /* Create the name of the lock-file for file fn */
-  MAKE_LOCK_NAME (lfname, encoded_fn);
-
   /* See if this file is visited and has changed on disk since it was
      visited.  */
   {
@@ -707,27 +700,35 @@ lock_file (Lisp_Object fn)
 
   }
 
-  /* Try to lock the lock.  */
-  if (0 < lock_if_free (&lock_info, lfname))
+  /* Don't do locking if the user has opted out.  */
+  if (create_lockfiles)
     {
-      /* Someone else has the lock.  Consider breaking it.  */
-      Lisp_Object attack;
-      char *dot = lock_info.dot;
-      ptrdiff_t pidlen = lock_info.colon - (dot + 1);
-      static char const replacement[] = " (pid ";
-      int replacementlen = sizeof replacement - 1;
-      memmove (dot + replacementlen, dot + 1, pidlen);
-      strcpy (dot + replacementlen + pidlen, ")");
-      memcpy (dot, replacement, replacementlen);
-      attack = call2 (intern ("ask-user-about-lock"), fn,
-		      build_string (lock_info.user));
-      /* Take the lock if the user said so.  */
-      if (!NILP (attack))
-	lock_file_1 (lfname, 1);
+
+      /* Create the name of the lock-file for file fn */
+      MAKE_LOCK_NAME (lfname, encoded_fn);
+
+      /* Try to lock the lock.  */
+      if (0 < lock_if_free (&lock_info, lfname))
+	{
+	  /* Someone else has the lock.  Consider breaking it.  */
+	  Lisp_Object attack;
+	  char *dot = lock_info.dot;
+	  ptrdiff_t pidlen = lock_info.colon - (dot + 1);
+	  static char const replacement[] = " (pid ";
+	  int replacementlen = sizeof replacement - 1;
+	  memmove (dot + replacementlen, dot + 1, pidlen);
+	  strcpy (dot + replacementlen + pidlen, ")");
+	  memcpy (dot, replacement, replacementlen);
+	  attack = call2 (intern ("ask-user-about-lock"), fn,
+			  build_string (lock_info.user));
+	  /* Take the lock if the user said so.  */
+	  if (!NILP (attack))
+	    lock_file_1 (lfname, 1);
+	}
+      SAFE_FREE ();
     }
 
   UNGCPRO;
-  SAFE_FREE ();
 }
 
 void

bug#18828: 24.4; Early collision warning when 'create-lockfiles' is set to nil

[Dani Moncayo]

> Here you go (if no one objects, I will push this in a few days):

Hi Eli,

I've tested your patch and seems to fix the problem.

Thank you so much.

-- 
Dani Moncayo    "looking forward to this commit"

bug#18828: 24.4; Early collision warning when 'create-lockfiles' is set to nil

[Eli Zaretskii]

> Date: Mon, 4 May 2015 23:12:54 +0200
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 18828@debbugs.gnu.org
> 
> > Here you go (if no one objects, I will push this in a few days):
> 
> Hi Eli,
> 
> I've tested your patch and seems to fix the problem.
> 
> Thank you so much.

Thanks, I pushed it.