[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: save-buffer: avoid data loss on interrupt

From: Paul Eggert
Subject: Re: save-buffer: avoid data loss on interrupt
Date: Tue, 13 Dec 2011 12:03:23 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 12/13/11 09:13, Jim Meyering wrote:

> -      (if (or (and file-precious-flag dir-writable)
> +      (if (or (and dir-writable
> +                (or file-precious-flag
> +                    (= (file-nlinks buffer-file-name) 1)))

I like the general idea, but this solution seems a bit aggressive,
as it will cause the file's ownership to change
if the file's link count is 1, and often that isn't what is wanted.
Instead, how about extending the semantics of break-hardlink-on-save,
with something like the following (untested) patch?

--- lisp/files.el       2011-12-04 08:02:42 +0000
+++ lisp/files.el       2011-12-13 19:46:33 +0000
@@ -4469,8 +4469,11 @@ Before and after saving the buffer, this
            (dir-writable (file-writable-p dir)))
       (if (or (and file-precious-flag dir-writable)
               (and break-hardlink-on-save
-                   (file-exists-p buffer-file-name)
-                   (> (file-nlinks buffer-file-name) 1)
+                  (let ((nlinks (file-nlinks buffer-file-name)))
+                    (and nlinks
+                         (> nlinks (if (numberp break-hardlink-on-save)
+                                       break-hardlink-on-save
+                                     1))))
                    (or dir-writable
                        (error (concat (format
                                        "Directory %s write-protected; " dir)

That way, you can set break-hardlink-on-save to -1 to get
the behavior that you want.

While we're on the subject, break-hardlink-on-save is not
documented; I wonder why not?  Also, the current code
does not work if the directory is sticky and writable
and the file is owned by someone else (a common situation
in /tmp); this should get fixed too.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]