"Erik Berry" <eb@techie.ZZZcom> wrote in message
news:45d525e5$1@newsgroups.borland.com...
> I looked at the vendor bug database, and they have had similar bugs
(I
> noticed later that this isn't the same bug I found, but this fix may
be the
> cause of the bug I see):
> http://bugs.proftpd.org/show_bug.cgi?id=2229
Technically speaking, having LIST and NLST return a 450 error when
listing an empty directory is allowed by RFC 959.
> I debugged into the Indy code, and the server does not appear to
send
> a 150 in response to an NLST request when in empty dirs the same as
> it does for non-empty dirs, and this is what causes causes Indy to
hang.
It will not cause a hang. If the server sends anything other than
125, 150, or 154, an exception is raised. So what EXACTLY is the
server really sending? Again, please provide details about the actual
FTP traffic that is being exchanged. That is why I told you to use a
packet sniffer.
> here is a full log I generated yesterday of the send/recv strings
Rather than trying to get that data manually, you could simply attach
a TIdLog... component to TIdFTP.
In any case,
> PORT 192,168,1,131,9,1
> 200 PORT command successful
> NLST
> 226 Transfer complete.
If that is all the server is actually sending, then the server really
is faulty to begin with, and needs to be fixed.
> Then this is raised:
As it should be. The server sent the wrong reply. There is nothing
Indy can do about that, other than to raise an exception.
> Finally, the last line of FinalizeDataOperation in
TIdFTP.InternalGet hangs
> for several minutes until it times out.
As it should be. The server is sending replies in the wrong order, so
it is going to confuse Indy and make it try to read more data than
will actually be sent..
Gambit
