Re: EFS 1.6 (dired?) problem with re-starting ftp process
sandy@ibm550.sissa.it
Thu, 21 Apr 1994 15:18:57 +0100
>>>>> On Fri, 8 Apr 1994 10:05:03 -0400,
Stainless Steel Rat <ratinox@ccs.neu.edu> said:
>>>>>> "Michael" == Michael Sperber [Mr Preprocessor]
>>>>>> <sperber@provence.informatik.uni-tuebingen.de> writes:
>Michael> - I fire up dired on a remote directory
>Michael> - I kill the corresponding ftp process buffer
>Michael> - I issue a "C" on a file "foobar" from the directory
>Michael> - EFS starts a new ftp process (great feature!)
>Michael> - ... but then starts a "listing directort /foobar"
> That's actually a feature. efs needs to make sure that the file you're
> looking for actually exists. Since the ftp protocol doesn't have a stat()
> function, the only way to make sure the file exists is to try and get a
> directory listing of it.
This is true, but this feature isn't "all that it could be". In the
next release, there will be two ways to kill an FTP process. In fact,
1.6 already has some of this support, but I hadn't finished it, so
it's not really all there.
The terminology is that you can "kill" a process, or "close" a
connection. Both kill the FTP client, but killing also wipes efs's
directory cache, and closing does not. If you you only close, efs
will not re-list, but simply assume that all files which existed
before the connection was lost still exist, and have all the same
attributes. The use of killing is that it fixes things if efs and the
connection are all muddled. In dired there will be keys to do either
to taste. FTP server time-outs will be equated with "closing".
Actually doing kill-buffer on the FTP process buffer will remain
equated with killing, as to my mind such brutal behaviour is more
suited to scrambled connections. Also, if dired isn't running, there
is an interactive command to close the connection associated with the
current buffer.
The next release is nearly ready, but I've been travelling a lot
recently. Life will settle down in a week, and then we can get it
out.
--sandy