|Subject:||Re: CRC bug|
|Posted by:||J. Peter Mugaas (oma002…@mail.wvnet.edu)|
|Date:||Mon, 13 Sep 2004|
On Sun, 12 Sep 2004 09:43:08 +0800, Michael J. Leaver wrote:
> In the function TIdFTP.CRC, the call to StrToIntDef() should be a call
> to StrToInt64Def() (it's 64 bits).
I have gone ahead and made that change.
> This is not related to Indy, but I found that the Raiden 2.4 FTP server
> will return the last CRC value it calculated if you try and get the CRC
> value of a file that does not exist.
I've noticed that oddity myself and I think mistakenly reports the results
from the last command. There is a thread about this on Raiden's support
Another thing I saw was that FFFFFF was reported for directories instead of
an error code. I've mentioned that on Raiden's forms.
BTW: I also fixed that compiler warning about an abstract method. I had
started on seeing if there was a way to decompress data directly from the
IOHandler but that did not work out the way I had hoped. I'm still
thinking that it may be possible to do that (it might increase
performance). The thing is that there is an inconsistency in the FTP
Deflate drafts. One says to some headers while another says that you
CRC bug posted by Michael J. Leaver on Sun, 12 Sep 2004