bugmldonkey, a multi-networks file-sharing client - Bugs: bug #11872, "Reshare" doesn't check...

 
 

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

bug #11872: "Reshare" doesn't check for removed files.

Submitter:  None
Submitted:  Sun 06 Feb 2005 02:09:01 PM UTC
   
 
Category:  Core Severity:  4 - Important
Item Group:  Program malfunction Status:  Duplicate
Assigned to:  None Open/Closed:  Closed
Release:  2-5-30-4 Release: 
Operating System:  Mac OS X 10.3 Binaries Origin:  None
CPU type:  PowerPC

Jump to the original submission

Thu 19 May 2005 02:19:36 PM UTC, comment #11: 

Duplicate of bug #12899

spiralvoice <spiralvoice>
Group administrator
Tue 12 Apr 2005 06:05:34 PM UTC, comment #10: 

see savannah bug #10250 for some more info.

Amorphous <amorphous>
Sat 09 Apr 2005 12:11:12 PM UTC, comment #9: 

Some new observations, I big holiday movie with over 2000 sources
just finished and appears 19 times in upstats, the first three
entries in upstats have different (=wrong) hashes than the rest
which have the correct hash (checked with ed2k_hash).

Are completed files rehashed after being commited? If yes, it looks
to me that the core takes hashes at times when hashing has not
completed yet (I use threaded cores).

On the second of those three entries with a wrong hash I got 113
requests and upload 15.6M according to upstats, according to
stats.razorback2.com that hash does not exist on the ed2k network
so I guess that number reflects the upload before the file finished
on my machine. The core has an uptime of 0d 19h.

Then I have 16 lines where the ed2k link is exactly the same,
here is how the list looks like when it comes to number of
requests and uploaded data (Entries without a second value had 0
bytes upload):

99
557
0
0
0
356
388
1
0
463
5818 1.7M
50
53
63
65
87

During the time I wrote this I got a 19th entry with correct
hash and 27 requests, 0 upload, other numbers stayed the same.
I guess the longer the core is not restarted the more entries
the file will have in upstats. (I just finished this text and
there is now a 20th entry...)

And now the funny thing: Sancho displays 16 lines of the file,
all with correct hash, so it ommits the three lines from upstats
which had a wrong hash.
That file is present twice in shared_files_new.ini, one time
with its filename in ./incoming/files, the second time with
./temp/urn_ed2k_... They both have the same partial hashes.


Then another finished file, I removed it already from ./incoming/files
It appears once in Sancho and three times in upstats, the hashes
in upstats are all different and the hash displayed in Sancho
is also different, so I have four different hashes for that file,
but all are incorrect (checked twice with ed2k_hash).
That file is also present twice in shared_files_new.ini, first
with its filename in ./incoming/files, the second time with
./temp/urn_ed2k_... They both have the same partial hashes which
are also the exact partial hashes by ed2k_hash so I donĀ“t know
where the different ed2k hashes displayed by HTML interface and
Sancho come from...

spiralvoice <spiralvoice>
Group administrator
Sat 19 Mar 2005 06:37:56 AM UTC, comment #8: 

---spiralvoice said on irc:
My problem happened with the file present in ./incoming/files without touching the core except displaying upstats
the finished file 25x in upstats was with several version. Its easy to reproduce: Search for txt files with avail>500 and size < 10kb
---

i tried that and the file did only appear once in sancho (even after restarting sancho). but multiple times in output of the command upstats (some files that i only shared even appeared multiple times. but i did already run reshare multiple times to unshare some files successfully, these were not displayed in sancho after it's restart anymore, but now i see they are still in upstats). (btw. sancho has a bug where files that are not shared anymore are still displayed in the shares tab after updating it.) seems like the code for upstats and for the gui-upstats is a bit different.

so when unsharing a file (by removing it from the share and issuing reshare), it seems to unshare the file for the donkey network (only one i tried), but the file has still a swarmer and still appears in upstats, but not in the sancho-gui (didn't try others).

savannah bug #12372 [starting downloads (that mlnet already had in it in that session) fails until restart] seems to be related to this bug

Amorphous <amorphous>
Wed 16 Mar 2005 01:08:36 AM UTC, comment #7: 

that patch will be in my .30ab and is in 30b from spiralvoice.

Amorphous <amorphous>
Sat 12 Mar 2005 06:22:25 PM UTC, comment #6: 

Please try patch #3822, coded by Amorphous

spiralvoice <spiralvoice>
Group administrator
Wed 02 Mar 2005 11:49:11 AM UTC, comment #5: 

Bug is still present in 2-5-29

spiralvoice <spiralvoice>
Group administrator
Thu 24 Feb 2005 11:50:56 AM UTC, comment #4: 

Also several other files which finished, I downloaded and removed them from incoming are still listed in upstats but not in Sanchos share list... And I bet the file which is displayed five times will also disappear.

spiralvoice <spiralvoice>
Group administrator
Thu 24 Feb 2005 11:47:53 AM UTC, comment #3: 

Last night two holiday movies finished, one is only once in upstats (correct), the other file is there six times, hm. All have same name, same hash and some requests, but only one has far more requests than the others (9600 compared to 20-90) and also uploads. I guess this is the file record for the file before it was commited. Also interesting that data for that only show up in upstats and not in Sancho GUI, Sancho shows that file only five times... This happens on Linux i386.

spiralvoice <spiralvoice>
Group administrator
Wed 16 Feb 2005 11:21:48 AM UTC, comment #2: 

Bug is also in 2.5.28s1
the duplicates are currently downloaded files
(no restart in the meantime)

So MLdonkey floods the servers with new file messages

Anonymous
Wed 09 Feb 2005 05:40:29 PM UTC, comment #1: 

have the same problem with the duplicates,
one file is 7 times listed in the upstats
same lenght same hash

all other files are listed once
but they are in subdirectories
don't know if there is a coherence

linux, mlnet 2-5-28r
binaries from siralvoice

Anonymous
Sun 06 Feb 2005 02:09:01 PM UTC, original submission:  

$subject. So at moment it is impossible to unshare file: mlnet will still show it in "Uploads", even if file already removed from hard drive.

Additionally, I think related, in web-ui, "Uploads" shows duplicates: the file will have multiple entries, but with different requests/etc values.

P.S. Binary from http://www.macresourcecenter.net/ by Raff67.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

CC list is empty

 

There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

 

Follow 11 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2005-05-19 spiralvoice StatusNone Duplicate
    Open/ClosedOpen Closed
2005-04-09 spiralvoice Severity3 - Normal 4 - Important
    Release2-5-30 2-5-30-4
2005-03-19 amorphous Severity6 - Security 3 - Normal
    StatusFixed None
2005-03-16 amorphous StatusNone Fixed
2005-03-12 spiralvoice Release2-5-28-1 2-5-30
2005-02-24 spiralvoice Severity3 - Normal 6 - Security
    Release2-5-28 2-5-28-1
    Release2.5.28

Back to the top

Powered by Savane 3.13-758e.
Corresponding source code