all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Jim Meyering <jim@meyering.net>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: Emacs development discussions <emacs-devel@gnu.org>
Subject: Re: save-buffer: avoid data loss on interrupt
Date: Tue, 13 Dec 2011 21:52:49 +0100	[thread overview]
Message-ID: <87d3bsqjmm.fsf@rho.meyering.net> (raw)
In-Reply-To: <4EE7AF8B.2090303@cs.ucla.edu> (Paul Eggert's message of "Tue, 13 Dec 2011 12:03:23 -0800")

Paul Eggert wrote:
> 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.

That'd be ok, but doesn't this deserve to be enabled more often
than when someone tweaks the break-hardlink-on-save variable?

How about this instead, assuming a file-owner-uid function?
(or if the two users of file-attributes is an issue,
we could combine file-nlinks and file-owner-uid into
a function that calls file-attributes just once)

Sure, this might still change the group, but if that's an issue
we could compare it to the default group.

diff --git a/lisp/files.el b/lisp/files.el
index 535715c..b0f01f2 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -4469,7 +4469,8 @@ Before and after saving the buffer, this function runs
            (dir-writable (file-writable-p dir)))
       (if (or (and dir-writable
 		   (or file-precious-flag
-		       (= (file-nlinks buffer-file-name) 1)))
+		       (and (= (file-nlinks buffer-file-name) 1)
+			    (= (file-owner-uid buffer-file-name) (user-uid)))))
               (and break-hardlink-on-save
                    (file-exists-p buffer-file-name)
                    (> (file-nlinks buffer-file-name) 1)



  reply	other threads:[~2011-12-13 20:52 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-09 10:26 enabling atomic-update more often, i.e., rewrite via rename Jim Meyering
2011-12-13 17:13 ` save-buffer: avoid data loss on interrupt Jim Meyering
2011-12-13 20:03   ` Paul Eggert
2011-12-13 20:52     ` Jim Meyering [this message]
2011-12-13 21:47       ` Paul Eggert
2011-12-13 22:27         ` chad
2011-12-14 14:40         ` Jim Meyering
2011-12-14 18:51           ` Paul Eggert
2011-12-15 23:53             ` Stefan Monnier
2011-12-14  2:40   ` Stefan Monnier
2011-12-15 12:58   ` Jim Meyering

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d3bsqjmm.fsf@rho.meyering.net \
    --to=jim@meyering.net \
    --cc=eggert@cs.ucla.edu \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.