[Mldonkey-bugs] [bugs #8488] inconsistant hash of odd sized files w.r.t. other clients

[spiralvoice]

This mail is an automated notification from the bugs tracker
 of the project: mldonkey, a multi-networks file-sharing client.

/**************************************************************************/
[bugs #8488] Latest Modifications:

Changes by: 
                spiralvoice <address@hidden>
'Date: 
                Tue 04/13/04 at 19:58 (Europe/Berlin)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | None                      | Wont Fix


------------------ Additional Follow-up Comments ----------------------------
> Maybe a recover_temp is done automatically at startup?
I think yes, until 2-5-16. In 2-5-17 (experimental!) there is a new option: 
recover_temp_on_startup yes|no

Can I close this bug? It seems to happen only when the disk gets full.






/**************************************************************************/
[bugs #8488] Full Item Snapshot:

URL: <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=8488>
Project: mldonkey, a multi-networks file-sharing client
Submitted by: rgselk
On: Wed 04/07/04 at 14:36

Category:  Core
Severity:  5 - Average
Item Group:  Program malfunction
Resolution:  Wont Fix
Assigned to:  None
Status:  Open
Release:  2.5.16
Release:  
Platform Version:  Linux
Binaries Origin:  CVS / Self compiled
CPU type:  Intel x86


Summary:  inconsistant hash of odd sized files w.r.t. other clients

Original Submission:  It looks like we need padding with null bytes for 
calculating the md4 hashes. I am downloading a file with an odd size: 187703295 
bytes (lastexile). I get an error for incorrect md4 for the last block over and 
over again. After adding one null byte to the file, the last md4 matches the 
md4 it was looking for...
I don't know if the padding needs to be a multiple of 2 bytes or more.


Follow-up Comments
------------------


-------------------------------------------------------
Date: Tue 04/13/04 at 19:58         By: spiralvoice
> Maybe a recover_temp is done automatically at startup?
I think yes, until 2-5-16. In 2-5-17 (experimental!) there is a new option: 
recover_temp_on_startup yes|no

Can I close this bug? It seems to happen only when the disk gets full.

-------------------------------------------------------
Date: Wed 04/07/04 at 19:33         By: rgselknospam
It is not 1.8 GB but 187 MB...
I started it at 2004-04-02 just after 9:00 (by cron).
CVS Tag: D2004.03.12.23.00.00
The temp file was one byte too short, no recover_temp done manually.

However I did have a 'disk full' at the same time. All downloads were paused. 
Maybe a recover_temp is done automatically at startup? I know I stopped it and 
I don't know if there was enough space for the *.ini files...

I just tested it again with a dummy md4 and the same size. The temp file was 
created with the correct size. This means it does not happen at creation time 
with enough disk space.


-------------------------------------------------------
Date: Wed 04/07/04 at 17:28         By: spiralvoice
As 1.8GB can normally not be downloaded in 24h;-) I would like to know with 
which core version you started the download, how long it was running and if you 
had to issue recover_temp because of lost ini files during the download 
process. Also I would like to know all core version you used for processing 
that particular file.

-------------------------------------------------------
Date: Wed 04/07/04 at 17:06         By: rgselknospam
It seems the error is somewhere else because when I look at the ed2k link I 
used, it does show 187703296 instead of 187703295...
This means the file created was one byte too short :-(













For detailed info, follow this link:
<http://savannah.nongnu.org/bugs/?func=detailitem&item_id=8488>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/