mldonkey, a multi-networks file-sharing client - Bugs: bug #8580, Writing into file in incoming...
You are not allowed to post comments on this tracker with your current authentication level.
bug #8580: Writing into file in incoming directory
Submitter: | Artifex Maximus <artifex> | ||
Submitted: | Thu 15 Apr 2004 01:04:41 PM UTC | ||
Category: | Core | Severity: | 1 - Wish |
Item Group: | Program malfunction | Status: | Fixed |
Assigned to: | None | Open/Closed: | Closed |
Release: | 2-5-16 | Release: | +Spiralvoice patch k |
Operating System: | FreeBSD | Binaries Origin: | CVS / Self compiled |
CPU type: | Intel x86 |
Jump to the original submission
Tue 10 Aug 2004 08:00:53 PM UTC, comment #16: |
Mark-Oliver Wolter <m-o-w> |
Tue 10 Aug 2004 06:45:02 PM UTC, comment #15: Changing severity to 1 because this bug might be solved in current CVS release. |
spiralvoice <spiralvoice> |
Tue 10 Aug 2004 02:54:02 PM UTC, comment #14: Please try CVS 2-5-27 and report if the bugs is solved |
spiralvoice <spiralvoice> |
Tue 10 Aug 2004 08:29:30 AM UTC, comment #13: The out-of-memory error is very hard to use, the only thing that could be useful to do would be to crash the program immediatly before it does any wrong to the files.
|
mldonkey admin <mldonkey> |
Tue 10 Aug 2004 03:47:03 AM UTC, comment #12: Upgraded the machine to 256MB last week, and started mlnet with ulimit of 150MB.
|
Mark-Oliver Wolter <m-o-w> |
Fri 23 Jul 2004 01:14:36 AM UTC, comment #11: Does any other user use ulimit to restrict memory usage?
|
Mark-Oliver Wolter <m-o-w> |
Thu 22 Jul 2004 11:58:51 PM UTC, comment #10: AFAICS there are no more Printf.printf commands left so I can't really say which part of the code is responsible. Do users of others OS's have the same problem? Here (x86 Linux) it never occured. |
spiralvoice <spiralvoice> |
Wed 09 Jun 2004 04:03:38 PM UTC, comment #9: With 2.5-16m:
|
Mark-Oliver Wolter <m-o-w> |
Mon 10 May 2004 02:02:35 PM UTC, comment #8: FreeBSD 4.x-STABLE, ocaml 3.07pl2
|
Artifex Maximus <artifex> |
Sun 09 May 2004 06:12:48 PM UTC, comment #7: I didn't. That was the mlnet from the mldonkey-2.5-16l.static.i386-Linux.rar archive you provided. |
Mark-Oliver Wolter <m-o-w> |
Sun 09 May 2004 03:29:38 PM UTC, comment #6: How did you compile MLDonkey? |
spiralvoice <spiralvoice> |
Sat 08 May 2004 07:53:32 PM UTC, comment #5: The problem is even worse than just what the patch addresses according to its description.
|
Mark-Oliver Wolter <m-o-w> |
Mon 26 Apr 2004 04:14:40 PM UTC, comment #4: I applied the patch and start to test. Any report will go to the patch section.
|
Artifex Maximus <artifex> |
Fri 23 Apr 2004 09:45:35 PM UTC, comment #3: Please try patch 2965 and report if it helps |
spiralvoice <spiralvoice> |
Sun 18 Apr 2004 09:42:23 AM UTC, comment #2: I take a look into the source and set min_users_on_server back to zero and therefore MLD never try to remove any server. Problem is gone but this is just a temporary solution, I think.
|
Artifex Maximus <artifex> |
Sat 17 Apr 2004 07:03:04 AM UTC, comment #1: It's happen again with another file. After that I upgraded my MLD to -18 and hope the problem is gone. BTW, I attached an image what happen with my file. It's looks like the log file goes into the file.
|
Artifex Maximus <artifex> |
Thu 15 Apr 2004 01:04:41 PM UTC, original submission:
I start to download a file. It's slowly finished, automatically moved to incoming and I received a notification mail. Great. Now comes the strange part. I download this file to my workstation. After that on the server in the incoming directory the mldonkey write anything (I don't know what) into that file. The md4 value changed of course but on my workstation the file's md4 is correct. What happen? Why MLD write to this file after committed? Strange...
|
Artifex Maximus <artifex> |
Depends on the following items: None found
Items that depend on this one: None found
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 6 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2005-02-01 | spiralvoice | Status | None | Fixed | |
Open/Closed | Open | Closed | |||
2004-08-10 | spiralvoice | Severity | 3 - Normal | 1 - Wish | |
2004-08-10 | mldonkey | Severity | 6 - Security | 3 - Normal | |
2004-04-23 | spiralvoice | Severity | 3 - Normal | 6 - Security | |
2004-04-17 | artifex | Attached File | - | Added 16hp_err_2.png, #1200 |
Powered by Savane 3.13-4448.
Corresponding source code
Is it even allowed to close stderr with ocaml?
If yes, then this is a bug in ocaml and not mlnet, as the text written appears only in the ocaml library functions (does it even return from the library call, or does it crash right away? I don't have the source here right now, only the static binaries, and wouldn't know where to look anyway).
If no, then stderr should not be closed but redirected to /dev/null or something.