Remy Lebeau (TeamB) wrote:
>> and it appears not to send
>> a 150 response to ls/NLST requests in empty directories.
>
> Yes, it does (or you would not be getting the 226 reply). The console
> output simply does not show it. That is why you need to use a better
> viewer of the FTP commands/replies.
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
I debugged into the Indy code, and the server does not appear to send 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. I was only
posting the ls output (which I know hides many things) to show this
difference in quick summary. The summary info wasn't convincing, so here is
a full log I generated yesterday of the send/recv strings from
TIdTCPConnection.SendCmd and TIdTCPConnection.GetInternalResponse:
...
AOut: 'FEAT'
LLine: '211-Features:'
LLine: 'MDTM'
LLine: 'REST STREAM'
LLine: 'SIZE'
LLine: '211 End'
AOut: 'TYPE I'
LLine: '200 Type set to I'
AOut: 'SYST'
LLine: '215 UNIX Type: L8'
AOut: 'PWD'
LLine: '257 "/" is current directory.'
AOut: 'TYPE A'
LLine: '200 Type set to A'
AOut: 'PORT 192,168,1,131,9,0'
LLine: '200 PORT command successful'
AOut: 'NLST' <note - in a non-empty directory, succeeds>
LLine: '150 Opening ASCII mode data connection for file list'
LLine: '226 Transfer complete.'
AOut: 'TYPE I'
LLine: '200 Type set to I'
AOut: 'CWD XXX' <into empty dir>
LLine: '250 CWD command successful'
AOut: 'TYPE A'
LLine: '200 Type set to A'
AOut: 'PORT 192,168,1,131,9,1'
LLine: '200 PORT command successful'
AOut: 'NLST' <note - in empty directory, fails, no 150 response>
LLine: '226 Transfer complete.'
Then this is raised:
EIdReplyRFCError "Transfer complete." with this call stack:
TIdReplyRFC.RaiseReplyError
TIdTCPConnection.RaiseExceptionForLastCmdResult
TIdTCPConnection.CheckResponse(226,...)
TIdTCPConnection.GetResponse
TIdTCPConnection.SendCmd('NLST',...)
TIdFTP.InternalGet('NLST',...,False)
TIdFTP.List(...,'',False)
Finally, the last line of FinalizeDataOperation in TIdFTP.InternalGet hangs
for several minutes until it times out.
If a workaround in Indy isn't practical, I'd suggest the Indy team add a
comment on this in the source to help others with this server. I'm no
longer affected by this issue, and won't be able to spend more time on it.
Good luck,
Erik
