What 'FtpOpenFile' really does is shown below:
1) Transfer method (always sent, even if 'INTERNET_FLAG_TRANSFER_UNKNOWN' is
200 Type set to I.
2) If 'InternetConnect' was specified with 'INTERNET_FLAG_PASSIVE':
227 Entering Passive Mode (192,168,42,3,5,244)
3) The 'SIZE' command (although it's not requested)
4) Finally, the 'RETR' command
150 Opening binary mode data connection for /Baddaysm.mpg (425988 bytes).
So far, there is no problem. with 'FtpOpenFile'. Just note the "SIZE"
command which is sent by 'FtpOpenFile'. That "SIZE" command is always sent,
even if no such information was requested. I think it's just sent to have
the size of the file available -- it's used internally by Wininet -- and to
have that information available when the application calls 'FtpGetFileSize'.
In fact, a call of 'FtpGetFileSize' will never generate a FTP "SIZE"
command -- it would be beyond the FTP specification.
Anyway, now to the bug.
If one uses the 'FtpCommand("RETR")' function to retrieve a file, Wininet
will send a *malformed* FTP "SIZE" command to the server.
Here's the documented trace:
1) Transfer method
200 Type set to I.
2) This is a non-PASSIVE transfer -- does not relate to the bug
200 PORT command successful.
3) The *malformed* SIZE command. It just seems that Wininet uses a filename
buffer which is not properly initialized because the characters following
the SIZE command are varying for each subsequent call.
550 <some-malformed-filename>: No such file or directory.
NOTE the '550' server reply! If the 'FtpCommand("RETR")' is used to perform
the request of a RESTarted file, the server will *reset* the file position
which was previously set with a "REST" command!
4) Finally the FTP command which was specified with 'FtpCommand', in that
case it's "RETR"
226 Transfer complete. 425988 bytes in 7 sec. (60.86 Kb/s).
Well, it seems that Wininet tries to use some code which is also used by
'FtpOpenFile', if the specified FTP command is "RETR".
Unfortunately, the most FTP servers which would support a FTP REST command,
if Wininet would send a proper sequence of FTP commands, just perform a
reset of the file position to the beginning of the file (BTW this is not
reported by a FTP reply code). So, if an application successfully sent a
REST <filepos> command and performs the "RETR <file>" command (with the
malformed "SIZE" command) the application has no chance to know whether the
FTP server has reset the file position or not.
I know, of course, that there will be no guarantee that a FTP RESTart will
work with Wininet if only that bug would be fixed, but it seems that most
FTP servers will tolerate at least the TYPE and/or PASV/PORT command which
is sent by Wininet. Although the FTP spec is quite clear in that point --
something like "the RETR command has to be sent immediately after the REST
command" -- there are some FTP servers which are quite tolerant. But none of
the FTP servers I've tested does tolerate a FTP command which created a
server error(!) between the REST and the RETR command!
I've observed this bug under all system configurations on which I've tested
it. In detail those configs are the following.
Win98, MSIE v5.01
Win98SE, MSIE v5.01
Win98SE, MSIE v5.5
Win2000, MSIE v5.5
Is there any workaround known?
"Markus Heiling" <x...@y.com> wrote in message news:#g31sVPOAHA.248@cppssbbsa04...