[Mldonkey-bugs] [ 100902 ] commit renames but does not move files

[nobody]

Support Request #100902, was updated on 2002-May-11 20:15
You can respond by visiting: 
http://savannah.gnu.org/support/?func=detailsupport&support_id=100902&group_id=1409

Category: None
Status: Closed
Priority: 5
Summary: commit renames but does not move files

By: mldonkey
Date: 2002-May-12 06:49

Message:
Logged In: YES 
user_id=5474
Browser: Mozilla/4.78 (Windows 98; U) Opera 6.01  [fr]

Did you change the use_mp3_tags option ? It should be set to "false" in 
1.15, because it doesn't work. I've noticed this behavior too, I think it 
is fixed. So, 1.16 should solve this problem next week.

The symlink 
should not be a problem. But I will check to be sure.

----------------------------------------------------------------------

By: richard.parry
Date: 2002-May-11 20:15

Message:
Logged In: NO 
Browser: Mozilla/5.0 Galeon/1.2.1 (X11; Linux i686; U;) Gecko/20020421 
Debian/1.2.1-1

WHen using commit in the 1.15 mldonkey command line
(586 shared version for Linux) the commit command will
rename the file within the temp folder, but will not
move it to incoming.

I believe this appears in the logs at about that time
(the lack of timestamping within the log does not help
track this):

256: Exceeding block boundaries
680259405-680263680 (700416000-710144000)
zone: 709816320-710000640zone: 710000640-710144000zone:
708894720-708894720ALREADY PRESENT

After manually moving the file, it does recognise the
existence of the new file in incoming:

NEW SHARED FILE
/home/mldonkey/mldonkey-shared/incoming/whatever.ext
Sharing
/home/mldonkey/mldonkey-shared/incoming/whatever.ext

Previously this was working with 1.14 using the i686
shared build, but on a completely seperate machine.

The only oddities I can think of:

incoming is a symlink to another folder, but this has
been tested to work on another system
filesystem is ext3, but this has been tested to work on
another system


----------------------------------------------------------------------
You can respond by visiting: 
http://savannah.gnu.org/support/?func=detailsupport&support_id=100902&group_id=1409