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

Submitter:  None
Submitted:  Tue 22 Mar 2005 02:47:48 AM UTC
   
 
Category:  Core Severity:  5 - Blocker
Item Group:  Program malfunction Status:  Fixed
Assigned to:  None Open/Closed:  Closed
Release:  2.5.30.15 Release: 
Operating System:  MinGW W2K/WinXP Binaries Origin:  Downloaded from third-party page
CPU type:  Intel x86

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>
Group administrator
Fri 27 May 2005 08:18:14 PM UTC, comment #24: 

Fixed by patch #4043

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

we not, you ;)

Schlumpf <schlumpf_>
Group 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>
Group 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_>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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_>
Group 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>
Group 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_>
Group 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>
Group 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_>
Group 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>
Group 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>
Group 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>
Group 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_>
Group 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>
Group 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>
Group 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>
Group 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>
Group 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

 

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

Date Changed by Updated Field Previous Value => Replaced by
2005-05-27 spiralvoice StatusNone Fixed
    Open/ClosedOpen Closed
2005-05-27 spiralvoice Attached File#2543 Removed
2005-05-26 spiralvoice Attached File- Added getsize.patch, #2543
2005-05-26 spiralvoice Attached File#2538 Removed
2005-05-23 spiralvoice Attached File- Added read.patch, #2538
2005-05-23 spiralvoice Attached File#2537 Removed
2005-05-23 spiralvoice Attached File- Added read.patch, #2537
2005-05-23 spiralvoice Attached File#2534 Removed
2005-05-23 spiralvoice Attached File#2532 Removed
2005-05-23 spiralvoice Attached File- Added read.patch, #2534
2005-05-22 spiralvoice Attached File- Added read.patch, #2532
2005-05-22 spiralvoice Attached File#2529 Removed
2005-05-22 spiralvoice Attached File#2528 Removed
2005-05-22 spiralvoice Attached File- Added read2.patch, #2529
2005-05-22 spiralvoice Severity3 - Normal 5 - Blocker
    Release2.5-28.1
2005-05-22 spiralvoice Attached File- Added read.patch, #2528
2005-05-22 spiralvoice Release2-5-28-1 2.5.30.15
    Operating SystemCygwin W2K/WinXP MinGW W2K/WinXP
2005-03-22 amorphous Summarycan'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.13-02a9.
Corresponding source code