[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FS:DIRECTORY-LIST & IP-TCP/FTP
Date: Thu, 10 May 90 09:06 PDT
From: email@example.com (Stephen L. Nicoud)
When I try to read my unix mail inbox "/usr/spool/mail/snicoud" I
sometimes have to wait five or more minutes while my Symbolics waits for
a directory listing of our Ultrix host's /usr/spool/mail directory,
which is very large.
So, I think I've traced it down to a call to FS:DIRECTORY-LIST which is
passed "bcsaic:/usr/spool/mail/snicoud.zmail" (the .zmail file being the
renamed file for my inbox). The Ultrix host has FTP as its only FILE
service. Well my Symbolics (7.2 ip-tcp 67.8 (eco 3)) asks Ultrix for
listing of "/usr/spool/mail". Why should it do that? Why not the whole
spec: "/usr/spool/mail/snicoud.zmail"? Is this a bug in IP-TCP or is
this a bug at all?
Has anyone else noticed this behavior?
I noticed it and patched around it. The reason it behaves this way is
because the Unix FTP server's LIST command behaves differently depending
on whether the argument you give is the name of a file or a directory.
Thus, if you did
this would translate to the FTP command
and Unix would then list the *contents* of the mail directory rather
than the mail directory entry itself. Symbolics's way of dealing with
this is to always ask for the listing of the directory contents and then
search the results itself.
The reason the FTP server behaves this way is that it simply constructs
a command line that calls the /bin/ls program. This explanation led me
to the realization that a better workaround is to prepend the "-d"
option to the argument, since this tells /bin/ls not to list directory
contents. With this change in place I also found that I could implement
wildcard lookups by sending the wildcarded name to the server rather
than asking for the whole directory and doing the matching locally.
I'll send you my patches under separate cover. They work in both 7.2