[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5. 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

 
elisp-code-efs@nongnu.org

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.

[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by XEmacs shared group account on December, 19 2009 using texi2html 1.65.