Bugs and Wish List
******************

   If you find any bugs or problems with this package, *please* e-mail
the authors. Ideas and constructive comments are especially welcome. So
are any enhancements to EFS, preferably debugged and documented. Also
welcome are any typo fixes, corrections or additions to this manual.

   Report a bug by typing

     M-x efs-report-bug

   or send mail to

     efs-bugs@hplb.hpl.hp.com

   EFS is a "free" program. This means that you didn't (or shouldn't
have) paid anything for it. It also means that nobody is paid to
maintain it, and the authors weren't paid for writing it.  Therefore,
please try to write your bug report in a clear and complete fashion. It
will greatly enhance the probability that something will be done about
your problem.

   Note that EFS relies heavily in cached information, so the bug may
depend in a complicated fashion on commands that were performed on
remote files from the beginning of your Emacs session. Trying to
reproduce your bug starting from a fresh Emacs session is usually a
good idea.

   Here is a list of known bugs:

   If you hit a bug in this list, please report it anyway. Most of the
bugs here remain unfixed because they are considered too esoteric to be
a high priority. If one of them gets reported enough, we will likely
change our view on that.

  1. EFS does not check to make sure that when creating a new file, you
     provide a valid filename for the remote operating system.  If you
     do not, then the remote FTP server will most likely translate your
     filename in some way. This may cause EFS to get confused about
     what exactly is the name of the file.

  2. For CMS support, we send too many `cd''s. Since `cd''s are cheap,
     I haven't worried about this too much. Eventually, we should have
     some caching of the current minidisk. This is complicated by the
     fact that some CMS servers lie about the current minidisk, so
     sending redundant cd's helps us recover in this case.

  3. The code to do compression of files over ftp is not as careful as
     it should be. It deletes the old remote version of the file, before
     actually checking if the local to remote transfer of the
     compressed file succeeds. Of course to delete the original version
     of the file after transferring the compressed version back is also
     dangerous, because some OS's have severe restrictions on the
     length of filenames, and when the compressed version is copied
     back the `"-Z"' or `".Z"' may be truncated. Then, EFS would delete
     the only remaining version of the file.  Maybe EFS should make
     backups when it compresses files (of course, the backup `"~"'
     could also be truncated off, sigh...).  Suggestions?

  4. If a dir listing is attempted for an empty directory on (at least
     some) VMS hosts, an ftp error is given. This is really an ftp bug,
     and I don't know how to get EFS work to around it.

  5. EFS gets confused by directories containing file names with
     embedded newlines. A temporary solution is to add `"q"' to your
     dired listing switches. As long as your dired listing switches
     also contain `"l"' and either `"a"' or `"A"', EFS will use these
     switches to get listings for its internal cache. The "q" switch
     should force listings to be exactly one file per line. You still
     will not be able to access a file with embedded newlines, but at
     least it won't mess up the parsing of the rest of the files.

  6. EFS cannot parse symlinks which have an embedded `" -> "' in their
     name. It's alright to have an embedded `" -> "' in the name of any
     other type of file. A fix is possible, but probably not worth the
     trouble. If you disagree, send us a bug report.

  7. EFS doesn't handle context-dep. files in H-switch listings on
     HP's. It wouldn't be such a big roaring deal to fix this. I'm
     waiting until I get an actual bug report though.

  8. If a hard link is added or deleted, EFS will not update its
     internal cache of the link count for other names of the file.
     This may cause file-nlinks to return incorrectly. Reverting any
     dired buffer containing other names for the file will cause the
     file data to be updated, including the link counts.  A fix for
     this problem is known and will be eventually implemented. How it
     is implemented will depend on how we decide to handle inodes. See
     below.

  9. EFS is unable to parse R-switch listings from remote Unix hosts.
     This is inefficient, because EFS will insist on doing individual
     listings of the subdirectories to get its file information.  This
     may be fixed if there is enough demand.

 10. In file-attributes, EFS returns a fake inode number. Of course
     this is necessary, but this inode number is not even necessarily
     unique.  It is simply the sum of the characters (treated as
     integers) in the host name, user name, and file name. Possible
     ways to get a unique inode number are:

       1. Simply keep a count of all remote file in the cache, and
          return the file's position in this count as a negative number.

       2. For unix systems, we could actually get at the real inode
          number on the remote host, by adding an `"i"' to the ls
          switches.  The inode numbers would then be removed from the
          listing returned by `efs-ls', if the caller hadn't requested
          the `"i"' switch. We could then make a unique number out of
          the host name and the real inode number.

 11. EFS tries to determine if a file is readable or writable by
     comparing the file modes, file owner, and user name under which it
     is logged into the remote host. This does not take into account
     groups.  We simply assume that the user belongs to all groups. As
     a result we may assume that a file is writable, when in fact it is
     not.  Groups are tough to handle correctly over FTP. Suggestions?
     (For new FTP servers, can do a `"QUOTE SITE EXEC groups"' to
     handle this.)

 12. EFS does not interact well with certain non-standard FTP clients.
     Specifically, some Linux distributions ship an ftp client with GNU
     readline support compiled in.  This ftp client may produce escape
     sequences which confuse EFS.  One symptom of this problem is that
     EFS appears to hang after printing the following message:

          Logging in as user anonymous...

     To fix this problem, recompile the FTP client without readline
     support, or install a new FTP client without readline support and
     set `efs-ftp-program-name' to point to the new client.