bugmldonkey, a multi-networks file-sharing client - Bugs: bug #3705, auto_commit does not always rm the...

 
 

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

bug #3705: auto_commit does not always rm the file from download queue

Submitter:  Invalid User ID <#19233>
Submitted:  Tue 20 May 2003 02:49:57 PM UTC
   
 
Category:  Core Severity:  2 - Minor
Item Group:  None Status:  None
Assigned to:  None Open/Closed:  Closed
Release:  None Release:  2.4-0
Operating System:  Linux Binaries Origin:  CVS / Self compiled
CPU type:  None

Tue 02 Mar 2004 08:43:48 PM UTC, comment #4: 

This patch report is old. If the bug still exists in current
versions please post a new bug report - spiralvoice

spiralvoice <spiralvoice>
Group administrator
Wed 25 Feb 2004 01:17:25 AM UTC, comment #3: 

Please check if this bug still is in current CVS version.
You should a tarball of current CVS in files section of
this project: http://savannah.nongnu.org/download/mldonkey/

spiralvoice <spiralvoice>
Group administrator
Mon 01 Dec 2003 09:32:45 PM UTC, comment #2: 

duplicate of 2834

spiralvoice <spiralvoice>
Group administrator
Fri 06 Jun 2003 02:20:03 PM UTC, comment #1: 

Until now, I wasn't able to reproduce the bug with a different client than the Gtk1.2 one. Either I made a mistake on my 1st posting (and the bug is GUI related) or the thing that happened back the is very rare.
A "reconnect" cleans up the neverending downloads, so IMHO the severity of this bug may be changed to low.

Invalid User ID <#19233>
Tue 20 May 2003 02:49:57 PM UTC, original submission:  

It happened again yesterday: after approx. 12h, 2 files were correctly committed into the incoming dir, but they stayed in the DL queue (regardless the interface I use, so it is not a GUI problem).
Both files were shown as 100% complete, and the size was correct too. However, when using the Gtk-1.2 GUI, one packet was still shown blue (== missing). Thus, 2 DL slots were permanently occupied, but the dl'ed files were complete and ok.
To free the slots, I renamed one of the files and canceled the download, which worked fine (the file was still there but no longer in the dl queue). Then I canceled the other file, it was rm'ed from the incoming dir (stupid me). So it seems that even the file descriptor wasn't freed.
This is not a duplicate of #1108 since both filenames were us-ascii charset compilant.
The described phenomenon happens rarely, but if you dl a lot, it occures with some propability (I'd say 1-2 times in 24h). Propably the conditions for committing the file to incoming and removing it from the dl queue differ?
Sorry I can't help better, but this OCAML language is not for me...

Invalid User ID <#19233>

 

(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 2 latest changes.

Date Changed by Updated Field Previous Value => Replaced by
2004-03-02 spiralvoice Open/ClosedOpen Closed
2004-02-25 spiralvoice Severity3 - Normal 2 - Minor

Back to the top

Powered by Savane 3.13-4b48.
Corresponding source code