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
Report a bug by typing
or send mail to
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.
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.
For CMS support, we send too many
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.
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" 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...).
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.
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", 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.
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.
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.
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.
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.
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:
Simply keep a count of all remote file in the cache, and
return the file's position in this count as a negative number.
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
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.
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
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.
This document was generated
by XEmacs Webmaster on October, 2 2007