|Subject:||Re: Directory listing has NULs in it - so Indy cuts it off at first NUL|
|Posted by:||Remy Lebeau (TeamB) (firstname.lastname@example.org)|
|Date:||Fri, 14 Jul 2006|
"Dennis Wynne" <dwyn…@equinoxis.com> wrote in message
> I am connecting to some "strange" FTP server that has a directory
> listing that is in no format I have seen - or other programs like
> WS_FTP can decode.
There are literally dozens, if not hundreds, of FTP listing formats used
online. Until people started adopting the MLST command in recent years,
there was no established standard format for listings at all. People used
whatever they wanted, usually just piping out whatever their OS's
command-line listing provided..
> The trouble is the host is sending nulls in each line before the CR
> at the end of the line.
Indy doesn't care about nuls. It always reads everything from the socket,
and returns strings that contain whatever data was stored in memory. As
long as the CR is in there somewhere, the nuls should be getting preserved
during the reading.
The VCL, on the other hand, is a completely different beast. List()
downloads the data in its raw form into a TStringStream, and then passes the
TStringStream.DataString to the TStrings.Text property. The Text property
only works with null-terminated strings, even though Delphi Strings can have
embedded nuls in them. Using TStrings.LoadFromStream() instead of the
TStrings.Text property has the same problem. This is a design problem on
Borland's part for not taking the true String lengths into account properly.
> Short of having to do the work myself (sending the LIST command
> and capturing the raw data, then parsing)
That is exactly what you will have to do.
> is there any way to have Indy return all the raw data to me?
List() requires the use of a TStringList, which cannot handle the nuls. The
only way to get access to the raw data is with an Intercept. You could then
transform the data as it is being downloaded, changing nuls to spaces or
other similar "safe" character.
> Looking at the source ldest is declared as a tldStringStream for
> to place the results of the command, and this is then assigned to
> I assume that the data is getting truncated at this assign when it tries
to parse the
> long data into strings and set count - it his the NUL and stops with a
count of 1?
> So is there a why to get the LIST result in its ture RAW format?
Not directly, no.
Directory listing has NULs in it - so Indy cuts it off at first NUL posted by Dennis Wynne on Fri, 14 Jul 2006