sometimes clients cannt download files from my share.
on their side written: 'Could not open target file'
when I start valknut from command line i see this message (when they try to download)
some of clients on the other hand - can connect and downloads the same files (clients vertions, who connects - are the same)...
Logged In: YES
user_id=1639740
Originator: NO
OK, please run valknut with "-v --socketlog both"
'Could not open target file' suggests that either their download folder is wrong, or, maybe, the file has invalid characters in it's name. What encoding setting are you using? Is you system using UTF-8 ( echo $LANG )?
The dcsocket.log file of the failing transfers will probably be the most use.
Logged In: NO
$echo $LANG
ru_RU.UTF-8
(download folder of the client side - is realy ok - I try it byself on other pc)
Checking xml version ...
Compiled for '20631' using '20631'
Using Valknut: '0.3.13'
Checking dclib version ...
Using DCLib: '0.3.13'
Checking Qt (TM) version ...
Compiled for '3.3.8' using '3.3.8'
Checking Qt (TM) privates ...
private test ok !
/home/pac/.dc//emoticons.xml:2: parser error : Start tag expected, '<' not found
^
/home/pac/.dc/dchub.cfg:2: parser error : Start tag expected, '<' not found
^
CSearchIndex::CloseHashLeaves: leaves not open!
CSearchIndex::CloseHashLeaves: leaves not open!
CListenManager: start listen
listen on socket
ATR: '192.168.8.95:9999' 'P2P mynet HUB' 'p2p.mynet.ru:411'
ATR: '(null)' '192.168.8.95:9999' 'P2P mynet HUB' 'p2p.mynet.ru:411'
ATR COUNT: 0
ATR ADD
ATR CONNECT: 192.168.8.95:9999 mynet P2P HUB p2p.mynet.ru:411
CWT: 'Serg' on 'mynet P2P HUB'
CWT: Create new TransferBanObject '192.168.8.95'
CWT: Banlist count 1 objects
UWT: Search user in the waitlist
UWT: User found
CWT: CheckWaitTransfer II: Serg on mynet P2P HUB
CWT: Requestcount is now 1
LOCK 1 0 689
DIRECTION: level: LOCAL: 17287 REMOTE: 21350
DIRECTION: direc: LOCAL: 1 REMOTE: 2
DIRECTION: we are in upload mode ...
Warning! ADCGet without TTH is undocumented behaviour!
Warning! Removing leading / from filename for ADCGet without TTH
start upload ...'/home/Games/ROK [ru]2008/Thumbs.db' 3180/4500
end found
UWT: Search user in the waitlist
UWT: User found
UWT: Remove user 0
ATR: '192.168.8.95:9999' 'mynet P2P HUB' 'p2p.mynet.ru:411'
ATR: '(null)' '192.168.8.95:9999' 'mynet P2P HUB' 'p2p.mynet.ru:411'
ATR COUNT: 0
ATR ADD
ATR CONNECT: 192.168.8.95:9999 mynet P2P HUB p2p.mynet.ru:411
CWT: 'Serg' on 'mynet P2P HUB'
UWT: Search user in the waitlist
UWT: User found
CWT: CheckWaitTransfer II: Serg on mynet P2P HUB
CWT: Requestcount is now 2
LOCK 1 0 689
DIRECTION: level: LOCAL: 789 REMOTE: 14326
DIRECTION: direc: LOCAL: 1 REMOTE: 2
DIRECTION: we are in upload mode ...
Warning! ADCGet without TTH is undocumented behaviour!
Warning! Removing leading / from filename for ADCGet without TTH
start upload ...'/home/Games/ROK [ru]2008/Диск01/TUROK_INSTALL.mds' 0/8428
end found
Warning! ADCGet without TTH is undocumented behaviour!
Warning! Removing leading / from filename for ADCGet without TTH
start upload ...'/home/Games/ROK [ru]2008/Кряк ViTALiTY.zip' 0/3181617
end found
Warning! ADCGet without TTH is undocumented behaviour!
Warning! Removing leading / from filename for ADCGet without TTH
start upload ...'/home/Games/ROK [ru]2008/Описание.rtf' 0/6163
end found
Warning! ADCGet without TTH is undocumented behaviour!
Warning! Removing leading / from filename for ADCGet without TTH
start upload ...'/home/Games/ROK [ru]2008/Турок.wmv' 0/15517940
end found
UWT: Search user in the waitlist
UWT: User found
UWT: Remove user 0
this accounts cannt downloads (as i see - log - it writes "ban", but why and where i can remove it - i cannt find)
UWT: Search user in the waitlist
UWT: User found
UWT: Remove user 0
Running Transfers: 0
pthread_mutex_destroy: Device or resource busy
application exit ok 0
Logged In: YES
user_id=1639740
Originator: NO
According to your socketlog file, I cannot see any problem in what dclib is doing. The remote client asks for a file using ADCGET with a filename and dclib sends the ADCSND response with exactly the same filename. The filenames are encoded in UTF-8 which is what they should be for ADCGET/ADCSND. dclib then starts sending the file data but the remote client disconnects.
Your problem seem to be due to not using TTHs to request the files, and the other side using old DC++ versions. I have an idea:
Edit ctransfer.cpp, search for "ADCGet needed for compatibility with DC++ >= 0.696" and comment out the line below it so it reads:
//s += "ADCGet ";
and recompile dclib. This will cause the other client to use some other command to request the file. Trouble is, if they use UGetBlock, the filename used will still be in UTF-8. You may also need to comment out s += "XmlBZList " a few lines above it, but then I think you hit bugs in dclib (wrong encoding of non-xml lists for one) related to ancient protocol commands which no-one should be using anyway. But I'll try and get them fixed (it's really hard to test against ancient DC++ versions).
I'll add options to dclib so that these things can be disabled without hacking the source.
Also: what is your remote encoding setting? (I guess it's correct)
Let me know if anything helps.
Logged In: NO
remote encoding: WINDOWS-1251
all windows clients use dc++ = 0.689 (because of no hash in my share %-) )
I'm start using valknut from 0.3.7(with win-clients 0.689), - and in version 0.3.12 - all works fine, but then, i upgrades libs in my gentoo distribution and install valknut 0.3.13... after a while - i discover, that most of clients cannot download from me, and fall back to 0.3.12 - makes no result.. yesterday - I delete all *.bin files and recreate share.. it helps for a most of clients, but a bug, that I meet still exists - so i post it here...
I think, that feature "disable hash" - greate, because of my share about 26Tb, and calculate TTH for files too long (files can be moved, changed and so on...) (just refresh all files takes a lot of time, thats why I post in feature request - ask to be able remake a listing of shares individually for each shared dir ;) )
PS: I'll try to remake dclib and post result here.
Encode txt filelist to remote encoding
Logged In: YES
user_id=1639740
Originator: NO
Most likely you'll need to disable both ADCGet and XmlBZList and apply the attached patch to fix the encoding of text filelists.
It's not quite the same patch as what's going into svn because I'm changing things so they should work on non UTF-8 systems, as well as a load of other things.
File Added: dclib-0.3.13-fix-txtlist-encoding.patch
Logged In: NO
one more thing - I find looking this problem:
when there two filenames :
Hardy L., Quantum Theory From Five Reasonable Axioms.pdf
Hardy L., quantum theory From Five Reasonable Axioms.pdf
(files the same size, md5 - just names differs in 2 literal-letters)
download stucks, and clients cann't download files
Logged In: YES
user_id=1639740
Originator: NO
It's probably some problem due to file names are not case sensitive in Windows, and likewise in DC++. If you have files/folders differing only in case, which ones will appear in DC++ is undefined.
But one of the files should have been sent. Please tell me the exact $Get (or maybe $GetZBlock) command used, from the dcsocket.log just before the $Error reply.