bugmldonkey, a multi-networks file-sharing client - Bugs: bug #12415, shared and downloading files are...

 
 

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

bug #12415: shared and downloading files are rw-locked under windows

Submitted by:  None
Submitted on:  Tue 22 Mar 2005 02:47:48 AM UTC  
 
Category: CoreSeverity: 5 - Blocker
Item Group: Program malfunctionStatus: Fixed
Assigned to: NoneOpen/Closed: Closed
Release: Release: 2.5.30.15
Operating System: MinGW W2K/WinXPBinaries Origin: Downloaded from third-party page
CPU type: Intel x86

(Jump to the original submission Jump to the original submission)

Mon 30 May 2005 12:04:22 AM UTC, comment #25:

[quote]
[quote]
But it seems after an upload slot for a shared file is closed
the fileis still kept open...
[/quote]
can´t confirm that, i can delete these Files too
[/quote]

I could not verify it here in every situation so I made patch #4057 to be sure.

spiralvoice <spiralvoice>
Project Administrator
Fri 27 May 2005 08:18:14 PM UTC, comment #24:

Fixed by patch #4043

spiralvoice <spiralvoice>
Project Administrator
Fri 27 May 2005 07:44:41 PM UTC, comment #23:

we not, you ;)

Schlumpf <schlumpf_>
Project Member
Fri 27 May 2005 06:51:42 PM UTC, comment #22:

"but the Files are still shown in upstats, and after a Request from any File that was deletet the File was new created with 0 kb."

This is bug #12899.

As all the other stuff from this bug seems to be solved now I think
we can close this bug now, ok?

spiralvoice <spiralvoice>
Project Administrator
Fri 27 May 2005 05:03:51 PM UTC, comment #21:

quick test looks good.

I can delete all Files from the shared dir, without the Files that current be uploading.
I can delete all Files from the incoming dir, without the Files that current be uploading.

[quote]
But it seems after an upload slot for a shared file is closed
the fileis still kept open...
[/quote]
can´t confirm that, i can delete these Files too

but the Files are still shown in upstats, and after a Request from any File that was deletet the File was new created with 0 kb.

Schlumpf <schlumpf_>
Project Member
Fri 27 May 2005 04:54:59 PM UTC, comment #20:

"Have still to test what happens after a finished file is committed."
On Linux they are not open, good.

spiralvoice <spiralvoice>
Project Administrator
Thu 26 May 2005 01:07:11 PM UTC, comment #19:

With this new patch I can rename and move shared files on windows after a core start.
But it seems after an upload slot for a shared file is closed
the file is still kept open...
No file finished yet so I can´t say anything about it yet...

spiralvoice <spiralvoice>
Project Administrator
Thu 26 May 2005 11:32:11 AM UTC, comment #18:

Direct after core start no shared files are open.
Have still to test what happens after a finished file is committed.

spiralvoice <spiralvoice>
Project Administrator
Thu 26 May 2005 11:17:27 AM UTC, comment #17:

Without this new patch the following happens:

close_fds -> all sockets are closed
and are re-opened for up- and downloading files

reshare -> also not uploading files are re-opened and stay open

with this patch after close_fds and reshare only up-/downloading files are open

spiralvoice <spiralvoice>
Project Administrator
Thu 26 May 2005 11:01:40 AM UTC, comment #16:

I added a patch "getsize.patch" here which closes the file
after getting its size if it is not writable.
I have not tested it throughly but closing the shared file
works on Linux, but I did not test it yet in real life.

On Linux you can watch the open files with this command from
the core dir if you have the mlnet.pid patch which is already
part of current CVS.

ls -al /proc/`cat mlnet.pid`/fd

spiralvoice <spiralvoice>
Project Administrator
Wed 25 May 2005 01:41:46 PM UTC, comment #15:

Same thing is on Linux, you can delete a file from incoming/shared
dirs but the space is not released, regardless if upload takes
place or not. After close_fds the space is released, if you execute
close_fds before deleting the space is released immediatly.

So solving this bug should help Linux users as well.

spiralvoice <spiralvoice>
Project Administrator
Wed 25 May 2005 12:31:33 PM UTC, comment #14:

for a first Workaround to delete/remove files from incoming/shared directory, until the bug is solved, use the commad "close_fds" before delete/remove any file.

current uploadete Files cannot deletet after "close_fds", try to use the "nu" command to stop the upload (wait some minutes) then use again "close_fds" to close the current uploadet files.

Then it´s not necessary to Kill the core to empty the incoming and get free disk space.

Schlumpf <schlumpf_>
Project Member
Wed 25 May 2005 10:47:50 AM UTC, comment #13:

Playing files work with patch #4043 now, will leave the bug
open until the rename/delete problem is solved.

spiralvoice <spiralvoice>
Project Administrator
Wed 25 May 2005 09:40:56 AM UTC, comment #12:

no, i can´t delete any file with or withou the patch
But without the patch i also can´t play the Video files in the incoming, with the patch playing files with Media Player works.

Schlumpf <schlumpf_>
Project Member
Wed 25 May 2005 09:03:03 AM UTC, comment #11:

Can you delete files without this patch?
Without this patch playing media files worked with extension .wmv
but not .avi, with this patch also .avi can be played.

spiralvoice <spiralvoice>
Project Administrator
Wed 25 May 2005 04:26:29 AM UTC, comment #10:

i can´t Delete any File from Shared Dir and also from my Incoming.
All Files played with Media Player so far (only 3 Downloadet testet)

Schlumpf <schlumpf_>
Project Member
Tue 24 May 2005 09:26:07 AM UTC, comment #9:

Patch worked on Linux overnight without problems, no paused files,
no exceptions. Files can be played now with Windows Media Player.

"- Files cannot be moved or renamed, but can be deleted np."
This is still the case, I believe after getsize and other functions
the file descriptor is not closed. I will further investigate.

spiralvoice <spiralvoice>
Project Administrator
Mon 23 May 2005 10:02:47 PM UTC, comment #8:

Updated patch, added writable parameter to Unix32.getsize64.

All parts in the code which handle shared files use it with false,
all other parts with true so there should be no problem writing
downloaded data.

Windows files are not locked anymore with this patch but it still
needs testing.

spiralvoice <spiralvoice>
Project Administrator
Mon 23 May 2005 01:14:56 PM UTC, comment #7:

Patch updated
Already with the old version I had a bug which caused this log message:
"Exception in really_write: pos=25 len=4336, string length=4361
error: write failed: Bad file descriptor
File paused."

Do you also experience this?

spiralvoice <spiralvoice>
Project Administrator
Mon 23 May 2005 09:59:01 AM UTC, comment #6:

your Patch #2532 dont work, every try to add a Download fails with this error Message int he log:
"Exception open failedon C:\Programme\Mldonkey\temp\urn_ed2k_TheHashFromTheseFile: No such file or directory in Network.iter for Donkey"

Schlumpf <schlumpf_>
Project Member
Sun 22 May 2005 10:56:57 PM UTC, comment #5:

Updated patch because the core raised exception in os_ftruncate,
I found out that this function was called everytime when
shared files were scanned.

Truncate controls the length of a file:

if file_size <> zero then
Unix32.ftruncate64 t file_size;

but should it be used everytime? No:

if file_size <> zero &&
file_size <> (Unix32.getsize file_diskname) then
Unix32.ftruncate64 t file_size;

spiralvoice <spiralvoice>
Project Administrator
Sun 22 May 2005 02:49:15 PM UTC, comment #4:

After reading over NON_BLOCK I think it is not a good idea to
have it in the patch.
http://www.delorie.com/gnu/docs/glibc/libc_262.html

spiralvoice <spiralvoice>
Project Administrator
Sun 22 May 2005 01:39:00 PM UTC, comment #3:

please be careful with this one as I only tested it on Windows yet.

spiralvoice <spiralvoice>
Project Administrator
Sun 22 May 2005 01:29:47 PM UTC, comment #2:

Can confirm this: hashing and sharing files with MLDonkey 2.5.30.15
blocks access with Windows Media Player. VLC can play those files...
Problem is in Unix32.read which opens files rw by default...
Also some functions like getsize64 do this also...

I did several things which I will describe here, hashing a file
and playing it with Windows Media Player works here now.

First I appended ro_flag with Unix.O_NONBLOCK, can´t be bad:
http://pauillac.inria.fr/~guesdon/Tools/doc_ocaml_classic/Unix.html#TYPEopen_flag
| O_NONBLOCK ( Open in non-blocking mode )

Then changed commonHasher.ml to use this flag instead of a hardcoded one.

Then Unix32.FDCache.local_force_fd opened files rw by default
which was the source of the problems described in this bug.

Unix32.read calls DiskFile.read, MultiFile.read or Sparsefile.Read depending on filetype:

let read t file_pos string string_pos len =
flush_fd t;
match t.file_kind with
| DiskFile t -> DiskFile.read t file_pos string string_pos len
| MultiFile t -> MultiFile.read t file_pos string string_pos len
| SparseFile t -> SparseFile.read t file_pos string string_pos len

All those read functions like this one:

module DiskFile = struct
let read = FDCache.read

module FDCache = struct
let read file file_pos string string_pos len =
let fd = local_force_fd file in

called FDCache.local_force_fd which opens all files rw by default:

try
Unix.openfile t.filename rw_flag rights
with Unix.Unix_error( (Unix.EACCES | Unix.EROFS) ,_,_) ->
Unix.openfile t.filename ro_flag 0o400

I appended FDCache.local_force_fd with a flag to distinguish
between "ro" and "rw" and changed only this functions which are
clearly read-only functions to this flag and left the rest
untouched.

spiralvoice <spiralvoice>
Project Administrator
Tue 22 Mar 2005 06:26:59 AM UTC, comment #1:

the problem on windows is, when a file is opened the file is rw-locked per default. even files that are opened read-only are read-locked under win, or? (atm mldonkey opens all files rw, wich is a bad idea, too.) can the auto-read-lock be switched off? imho a bad choice by windows. locks are no bad idea, but perhaps they should be off per default, or only a write-lock for files that are opened writeable.

Amorphous <amorphous>
Tue 22 Mar 2005 02:47:48 AM UTC, original submission:

- rar and zip files produce a "cannot open" error from windoze.
- mp3s and avis are "in use by another process" according to media players when attempt is made to enqueue.
- Files cannot be moved or renamed, but can be deleted np.
- Affects any shared dirs, rendering sharing impracticable.
- When copied to nonshared dirs the files behave.

Using 2.5-28.1 spiralvoice win32 + web i/face under M$ win XP SP1. P4 1890MHz 1GB RAM, Nod32 antivirus.

Thanks for all your work

Anonymous

 

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 21 latest changes.

Date Changed By Updated Field Previous Value => Replaced By
Fri 27 May 2005 08:18:14 PM UTCspiralvoiceStatusNone=>Fixed
  Open/ClosedOpen=>Closed
Fri 27 May 2005 08:16:34 PM UTCspiralvoiceAttached File#2543=>Removed
Thu 26 May 2005 11:01:40 AM UTCspiralvoiceAttached File-=>Added getsize.patch, #2543
Thu 26 May 2005 10:58:51 AM UTCspiralvoiceAttached File#2538=>Removed
Mon 23 May 2005 11:28:34 PM UTCspiralvoiceAttached File-=>Added read.patch, #2538
Mon 23 May 2005 11:28:14 PM UTCspiralvoiceAttached File#2537=>Removed
Mon 23 May 2005 10:02:47 PM UTCspiralvoiceAttached File-=>Added read.patch, #2537
Mon 23 May 2005 09:16:48 PM UTCspiralvoiceAttached File#2534=>Removed
Mon 23 May 2005 01:15:06 PM UTCspiralvoiceAttached File#2532=>Removed
Mon 23 May 2005 01:14:10 PM UTCspiralvoiceAttached File-=>Added read.patch, #2534
Sun 22 May 2005 10:56:57 PM UTCspiralvoiceAttached File-=>Added read.patch, #2532
Sun 22 May 2005 10:54:28 PM UTCspiralvoiceAttached File#2529=>Removed
Sun 22 May 2005 02:49:57 PM UTCspiralvoiceAttached File#2528=>Removed
Sun 22 May 2005 02:49:15 PM UTCspiralvoiceAttached File-=>Added read2.patch, #2529
Sun 22 May 2005 01:39:23 PM UTCspiralvoiceSeverity3 - Normal=>5 - Blocker
  Release2.5-28.1=>
Sun 22 May 2005 01:39:01 PM UTCspiralvoiceAttached File-=>Added read.patch, #2528
Sun 22 May 2005 01:29:47 PM UTCspiralvoiceRelease2-5-28-1=>2.5.30.15
  Operating SystemCygwin W2K/WinXP=>MinGW W2K/WinXP
Tue 22 Mar 2005 06:26:59 AM UTCamorphousSummarycan't open rar zip mp3 avi files in /incoming and other shares=>shared and downloading files are rw-locked under windows

Back to the top


Powered by Savane 3.1-cleanup1