bugmldonkey, a multi-networks file-sharing client - Bugs: bug #8488, inconsistant hash of odd sized...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #8488: inconsistant hash of odd sized files w.r.t. other clients

Submitted by:  rgselk <rgselknospam>
Submitted on:  Wed 07 Apr 2004 02:36:24 PM UTC  
 
Category: CoreSeverity: 3 - Normal
Item Group: Program malfunctionStatus: Wont Fix
Assigned to: NoneOpen/Closed: Closed
Release: Release: 2-5-16
Operating System: LinuxBinaries Origin: CVS / Self compiled
CPU type: Intel x86

Wed 14 Apr 2004 05:02:37 PM UTC, comment #5:

Yes, you can close it. At least it is very low priority now.
Thanks anyway.

rgselk <rgselknospam>
Tue 13 Apr 2004 07:58:29 PM UTC, comment #4:

> 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.

spiralvoice <spiralvoice>
Project Administrator
Wed 07 Apr 2004 07:33:24 PM UTC, comment #3:

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.

rgselk <rgselknospam>
Wed 07 Apr 2004 05:28:24 PM UTC, comment #2:

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.

spiralvoice <spiralvoice>
Project Administrator
Wed 07 Apr 2004 05:06:47 PM UTC, comment #1:

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 :-(

rgselk <rgselknospam>
Wed 07 Apr 2004 02:36:24 PM UTC, 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.

rgselk <rgselknospam>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

Do you think this task is very important?
If so, you can click here to add your encouragement to it.
This task has 0 encouragements so far.

Only logged-in users can vote.

 

Please enter the title of George Orwell's famous dystopian book (it's a date):

 

 

Follow 2 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Sat 17 Apr 2004 02:10:12 AM UTCspiralvoiceOpen/ClosedOpen=>Closed
Tue 13 Apr 2004 07:58:29 PM UTCspiralvoiceStatusNone=>Wont Fix

Back to the top


Powered by Savane 3.1-cleanup1