bug#18125: file-precious-flag breaks symlinks

bug#18125: file-precious-flag breaks symlinks

[Glenn Morris]

Package: emacs
Version: 24.3.92

touch foo
ln -s foo bar
emacs-24.3.92  -Q --eval '(setq file-precious-flag t)' bar
change bar and save
   -> bar is no longer a symlink

AFAICS, it has always (since at least 22.3) been like this.
Does it have to be, though? Why can't it overwrite the target of the link?

In any case, the doc only mentions breaking hardlinks.

Setting find-file-visit-truename non-nil avoids the problem.

(Cf http://debbugs.gnu.org/454)

bug#18125: file-precious-flag breaks symlinks

[Lars Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> touch foo
> ln -s foo bar
> emacs-24.3.92  -Q --eval '(setq file-precious-flag t)' bar
> change bar and save
>    -> bar is no longer a symlink
>
> AFAICS, it has always (since at least 22.3) been like this.
> Does it have to be, though? Why can't it overwrite the target of the link?

This behaviour is still present in Emacs 28.

> In any case, the doc only mentions breaking hardlinks.
>
> Setting find-file-visit-truename non-nil avoids the problem.

I'm not sure whether this is a bug or whether it makes sense.  I'm
leaning towards...  bug?  Perhaps?  Anybody got an opinion here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#18125: file-precious-flag breaks symlinks

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 04 Dec 2020 12:40:19 +0100
> Cc: 18125@debbugs.gnu.org
> 
> Glenn Morris <rgm@gnu.org> writes:
> 
> > touch foo
> > ln -s foo bar
> > emacs-24.3.92  -Q --eval '(setq file-precious-flag t)' bar
> > change bar and save
> >    -> bar is no longer a symlink
> >
> > AFAICS, it has always (since at least 22.3) been like this.
> > Does it have to be, though? Why can't it overwrite the target of the link?
> 
> This behaviour is still present in Emacs 28.
> 
> > In any case, the doc only mentions breaking hardlinks.
> >
> > Setting find-file-visit-truename non-nil avoids the problem.
> 
> I'm not sure whether this is a bug or whether it makes sense.  I'm
> leaning towards...  bug?  Perhaps?  Anybody got an opinion here?

IMO, we could provide the alternative behavior as opt-in, conditioned
on a new option.  It is not clear to me that everyone will want to
overwrite the target, so an incompatible change here must be an
opt-in.

bug#18125: file-precious-flag breaks symlinks

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> IMO, we could provide the alternative behavior as opt-in, conditioned
> on a new option.  It is not clear to me that everyone will want to
> overwrite the target, so an incompatible change here must be an
> opt-in.

It's a pretty specialised option (which makes it hard to explain), but I
get your point about being backwards-compatible in this area.

So I've now added the new option and adjusted the code.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no