gaynor@porthos.rutgers.edu (Silver) (10/19/88)
I got burned by breaking a symbolic link chain, by the way GNU Emacs saves
files. I edited a link, not realizing that it wasn't the file I had intended
to edit. When I went to save the file, emacs did it's usual antics of moving
the previous contents to the backup file, and saved the buffer into a newly
created file. So, to avoid getting nuked in the future, I wrote a quickie
which (query) resolves links when a file is found. I didn't sit around and
test it for hours, but it worked on all of the nastiest cases I could think of
in half an hour. It is not armed to the teeth with features; the only effect
of installing it is the addition of a find-file hook and a tweek to
basic-save-buffer. I think things should be done in a similar fashion by
default, which is why you are seeing this on gnu.emacs.bug. I'd appreciate
hearing your comments if you have any.
Regards, [Ag] gaynor@rutgers.edu
--------------------------------- symlink.el ----------------------------------
;; GNU, it's yours if you want it. [Ag] gaynor@rutgers.edu
(provide 'symlink)
(defvar buffer-symlink-name nil
"Set to the name of the file at which a symbolic link chain should be broken
when performing a basic-save-buffer.")
(setq find-file-hooks
(cons 'find-file-symlink-hook
find-file-hooks))
(defun find-file-symlink-hook ()
"find-file hook which assigns buffer-symlink-name upon reading a file.
Interactively walks through a symlink chain until user chooses to break the
chain."
(set (make-local-variable 'buffer-symlink-name)
(resolve-symlink-name buffer-file-name)))
(defun resolve-symlink-name (file-name &optional quiet)
(let ((symlink-name file-name)
(sln (file-symlink-p file-name)))
(while (and sln
(or quiet
(y-or-n-p (format "Follow symlink %s to %s? "
symlink-name sln))))
(setq symlink-name (expand-file-name sln)
sln (file-symlink-p sln)))
symlink-name))
;; Redefine basic-save-buffer to give precedence to buffer-symlink-name if it
;; is non-nil.
(let ((bsb (symbol-function 'basic-save-buffer)))
(fset 'basic-save-buffer
(list (car (nthcdr 0 bsb)) ;; lambda
(car (nthcdr 1 bsb)) ;; arguments
(car (nthcdr 2 bsb)) ;; documentation
(car (nthcdr 3 bsb)) ;; interactive
(append '(let ((buffer-file-name (or buffer-symlink-name
buffer-file-name))
(real-buffer-file-name buffer-file-name)))
(nthcdr 4 bsb))))) ;; body of basic-save-bufferexodus@mfgfoc.uucp (Greg Onufer) (10/20/88)
From article <Oct.19.04.46.36.1988.22562@porthos.rutgers.edu>, by gaynor@porthos.rutgers.edu (Silver): > > I got burned by breaking a symbolic link chain, by the way GNU Emacs saves > files. I edited a link, not realizing that it wasn't the file I had intended > to edit. When I went to save the file, emacs did it's usual antics of moving > the previous contents to the backup file, and saved the buffer into a newly > created file. So, to avoid getting nuked in the future, I wrote a quickie On page 87 of my GnuEmacs manual (Section 15.3.1.3), a variable named "backup-by-copying-when-linked" is described. I think you should have a look at it. (RTFM) -Greg Onufer
steiner@topaz.rutgers.edu (Dave Steiner) (10/20/88)
In article <444@mfgfoc.uucp> exodus@mfgfoc.uucp (Greg Onufer) writes: > From article <Oct.19.04.46.36.1988.22562@porthos.rutgers.edu>, by gaynor@porthos.rutgers.edu (Silver): > > I got burned by breaking a symbolic link chain, by the way GNU Emacs saves > > files. I edited a link, not realizing that it wasn't the file I had intended > > to edit. [...] > On page 87 of my GnuEmacs manual (Section 15.3.1.3), a variable named > "backup-by-copying-when-linked" is described. I think you should have > a look at it. (RTFM) This is not a case of RTFM but is an actual bug. I reported it about a week ago and gave a solution. rms sent me mail saying it's already fixed but in a better way than the way I did it. The problem is the behavour with links is different when you have file-precious-flag set to t or not. ds -- arpa: Steiner@TOPAZ.RUTGERS.EDU uucp: ...{ames, cbosgd, harvard, moss}!rutgers!topaz.rutgers.edu!steiner