[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?
It is a bug that Unix does not have a way to get file property information on
a directory by using the ls command and most, if not all, Unix FTP servers
don't support the STAT command. While it seems perfectly correct to get the
information for your mail file using the specific file name, if the pathname
you asked for was a directory, you would get information on all the files in
the directory and no properties on the directory itself. So, the FTP code
assumes that the parent directory exists for the pathname you have asked for
and does a directory list of the the parent directory and extracts the
information on the file.
I agree that it is a real pain and I have thought about speeding it up. I
even came up with a patch to make it faster but ran into the behavior
mentioned above. I suppose one gross kludge would be to try listing the
specific file and if a long list gets returned, to try the parent directory
but that is pretty gross.
Use NFS? If you are willing to risk problems with getting properites on a
directory, I might be able to send you the patch that I made.
BTW, In 8.0, I fixed all the timing bugs with FTP connections being blown away
at inappropriate times.