Change in backup-buffer: how to interpret?

Change in backup-buffer: how to interpret?

[Kai Großjohann]

Between Emacs 21.2.93 and the current CVS, I see the following change
in backup-buffer.  (Actually, more stuff has changed.)

@@ -2147,13 +2356,17 @@
 (defun backup-buffer ()
   "Make a backup of the disk file visited by the current buffer, if appropriate.
 This is normally done before saving the buffer the first time.
-If the value is non-nil, it is the result of `file-modes' on the original
-file; this means that the caller, after saving the buffer, should change
-the modes of the new file to agree with the old modes.
 
 A backup may be done by renaming or by copying; see documentation of
 variable `make-backup-files'.  If it's done by renaming, then the file is
-no longer accessible under its old name."
+no longer accessible under its old name.
+
+The value is non-nil after a backup was made by renaming.
+It has the form (MODES . BACKUPNAME).
+MODES is the result of `file-modes' on the original
+file; this means that the caller, after saving the buffer, should change
+the modes of the new file to agree with the old modes.
+BACKUPNAME is the backup file name, which is the old file renamed."
   (if (and make-backup-files (not backup-inhibited)
 	   (not buffer-backed-up)
 	   (file-exists-p buffer-file-name)
@@ -2179,12 +2392,15 @@
 			    (or (eq delete-old-versions t) (eq delete-old-versions nil))
 			    (or delete-old-versions
 				(y-or-n-p (format "Delete excess backup versions of %s? "
-						  real-file-name))))))
+						  real-file-name)))))
+		      (modes (file-modes buffer-file-name)))
 		  ;; Actually write the back up file.
 		  (condition-case ()
 		      (if (or file-precious-flag
     ;			      (file-symlink-p buffer-file-name)
 			      backup-by-copying
+			      ;; Don't rename a suid or sgid file.
+			      (< 0 (logand modes #o6000))
 			      (and backup-by-copying-when-linked
 				   (> (file-nlinks real-file-name) 1))
 			      (and (or backup-by-copying-when-mismatch


As you can see, `modes' is the result of (file-modes
buffer-file-name), and later on (logand modes #o6000) is then
invoked.

I think that file-modes can return nil.  (Ange-FTP always returns
nil.)  Then the logand will fail.

So is it a bug in the current code (which should deal with a nil
return value of file-modes), or is it a bug in Ange-FTP (which
returns nil)?
-- 
Ambibibentists unite!

Re: Change in backup-buffer: how to interpret?

[Kai Großjohann]

kai.grossjohann@uni-duisburg.de (Kai Großjohann) writes:

> So is it a bug in the current code (which should deal with a nil
> return value of file-modes), or is it a bug in Ange-FTP (which
> returns nil)?

I think it would be a good idea to augment the documentation for
filename handlers.  Each operation should say what a filename handler
should do when it doesn't know.

Eg, I think that file-attributes is supposed to return -1 as a
don't-know value for uid and gid, and (0 0) as a don't-know value for
access, modification, and status change time.  But maybe I'm wrong --
that's even more of a reason for documentation ;-)
-- 
Ambibibentists unite!

Re: Change in backup-buffer: how to interpret?

[Richard Stallman]

    I think that file-modes can return nil.  (Ange-FTP always returns
    nil.)  Then the logand will fail.

    So is it a bug in the current code (which should deal with a nil
    return value of file-modes), or is it a bug in Ange-FTP (which
    returns nil)?

It's a bug in my change.  Thanks for reporting it--I will fix it.