Re: EFS 1.15 bug: efs changes permissions & ownership of files ?

Sandy Rutherford (sandy@math.ubc.ca)
Thu, 15 Oct 1998 16:05:34 -0700 (PDT) 

Ronald,

On Thu, 15 Oct 1998 you wrote:

 > Thanks.  I've enclosed the relevant section of an *ftp ...* buffer
 > with a failed chmod command, and below that the settings of the three
 > variables named in your last message.  The messages in the mode-line
 > of xemacs are too fast to read, but I believe when it fails to restore
 > the permissions and ownership I see a message about a `shell' command.
 > In this instance, the file started out 755 permissions and ended up
 > 644 permissions after editing with efs.  [The machine from which I'm
 > working and the machine on which I edited the file (jenny) are both
 > running Solaris-2.6.]

Let's have a look at the *ftp ...* buffer here.

   ftp> put /tmp/efsmCGG4_ /var/spool/fax/etc/FaxDispatch
   > 200 PORT command successful.
   > 150 Binary data connection for /var/spool/fax/etc/FaxDispatch (192.101.32.1,40496).
   > 226 Transfer complete.
   > local: /tmp/efsmCGG4_ remote: /var/spool/fax/etc/FaxDispatch
   > 1320 bytes sent in 0.0012 seconds (1074.22 Kbytes/s)
** ftp> quote site chmod 755 /var/spool/fax/etc/FaxDispatch
   > 502 SITE command not implemented.
   ftp> /var/spool/fax/etc
   > chmod: WARNING: can't change FaxDispatch

At "**" we can see the problem.  efs knows that the mode should be
755, but because the ftp server doesn't support the SITE chmod
command, it can't change it.  The 644 mode that the file gets would be
the umask of the ftpd on the server.

 > The *ftp ...* buffer for the other example (editing as root on the
 > machine where I am logged into the console) does not show failed chmod
 > commands.  On that machine efs changes the permissions (from 755 to
 > 644) and the ownership from bin:bin to root:other.  If I edit the file 
 > again before the ftp session times out, it does not change the
 > permissions or ownership.

In this case there are no failed chmod commands because
`efs-root-umask' is nil.  efs will not attempt to control the modes in
this case.

 > I'm not sure how the vanilla Solaris-2.6 ftp server would be the
 > culprit in this: it worked without changing permissions or owners with
 > ange-ftp.

Both ange-ftp and efs do all file handling via the ftp server, so any
problems with file ownership & modes will show in the *ftp ...*
buffer.  If the ftp server doesn't take "SITE chmod" commands, then
there is little that efs can do.  You are at the mercy of your ftp
server.  

One reason why the problem might have not have appeared with ange-ftp
is that ange-ftp may not be making backup files.  Below from your *ftp
...*, you can see the creation of the "~" backup file.

  ftp> delete /var/spool/fax/etc/FaxDispatch~
  250 DELE command successful.
  ftp> rename /var/spool/fax/etc/FaxDispatch /var/spool/fax/etc/FaxDispatch~
  350 File exists, ready for destination name
  250 RNTO command successful.
  ftp> put /tmp/efsmCGG4_ /var/spool/fax/etc/FaxDispatch
  200 PORT command successful.
  150 Binary data connection for /var/spool/fax/etc/FaxDispatch (192.101.32.1,40496).
  226 Transfer complete.
  local: /tmp/efsmCGG4_ remote: /var/spool/fax/etc/FaxDispatch
  1320 bytes sent in 0.0012 seconds (1074.22 Kbytes/s)

ange-ftp may simply be overwriting the previous file with a put
command, which may convince the ftp server to preserve the file modes.
This is one of the major differences between ange-ftp and efs.  efs
goes to a lot of pains to implement all of the emacs safety features
regarding file modtimes, backups, autosave files, etc with remote
files to the same level as local files.  A work around to your problem
would be to disable remote backups.  To do this use:

(defvar efs-make-backup-files efs-unix-host-types
  "*A list of operating systems for which efs will make Emacs backup files.
The backup files are made on the remote host.

For example:
'\(unix sysV-unix bsd-unix apollo-unix dumb-unix\) makes sense, but
'\(unix vms\) would be silly, since vms makes its own backups.")

Set this  to nil to totally disable backups.

By the way, the Sun FTP server is about the buggiest FTP server on the
planet.  I use a lot of Sun machines and am frequently annoyed by bugs
in their FTP server.  The best way to get satisfaction is to replace
it (for eg, with the wu ftp server).

-- 

Sandy Rutherford
Department of Mathematics
University of British Columbia
Vancouver, British Columbia
V6T 1Z2
Canada
sandy@math.ubc.ca