But i've encountered several problems that lead me to the conclusion that i am missing something here.

Right now my biggest problem is that sending queryHit with a different sha1 for the file (not the correct one, just one i made up) starts the DL, where as using the correct one (should be, i've calculated the sha1) give me "no sources" in gtk-gnutella and the DL won't start. Other than the sha1 - the queryHit is the same - but with the fake sha1 i also get the HTTP GET message that asks for the file and i don't get it using the real sha1.

The reason i'm doing that is to test calculating the sha1 for a file i already have - when using the fake sha1 after i finish DL (using both gtk-gnutella and Phex for DL the file from my program) - it gives me a message about wrong sha1 (of course, i made the sha1 up) and restarting DL. Now i wanted to check the correct sha1 - and expected not to see this message.

This is my biggest problem right now, please help.

The problem might be that Gtk-Gnutella remembers the SHA1s of files it has downloaded before. That could cause the "no sources" issue if you try to run your test multiple times. Remove ~/gtk-gnutella/done.* or hack the sources to skip this check in src/core/ignore.c.

But i have more info - the thing is more complex than what i thought:
My sha1 as i calculated it is: 3IRE53N5YXBD2AFSPHPWPMINI53O63DB.
If i change the first I to R or T - it works! meaning the only thing that does not work for me is this particular sha1 or something.

Also - this happens in LimeWire as well. I have the code on my Eclipse so i can debug it and see why the sha1 i've calculated using the LW/FW's code does not work (meaning it does not send me the GET message) but if i destroy it (change it randomally) - it does.

Any thoughts? Maybe where to look in the code (i'm starting digging, i'll see what i come up with).

Try a file consisting of 500 NUL bytes. What urn:sha1 do you get?

I printed this buffer - 500 times 0 that i've created like this:
ByteBuffer buffer = ByteBuffer.allocate(500);
printed to a file, than i asked my method call to generate sha1 for this and the result is: 7RLNJM6HFKF74WJTOPDUBVKY5QJUBLDT
Is it okay?

Other than that, i don't understand - if i faked a sha1 it asks for the file and if i give it the sha1 the i generated i don't? why is the fake better than the calculated one?

Yes, the SHA1 one is correct. If you share this file and report it in a query hit, there's no attempt at all to download it?

and still it asked me the file. I change only the sha1 to the one for the file with the nulls and i got a request:
GET /uri-res/N2R?urn:sha1:7RLNJM6HFKF74WJTOPDUBVKY5QJUBLDT HTTP/1.1

Why when i change the sha1 to the URN for the real file it doesn't request anything? it doesn't check for validation, so what's wrong?
Again, the only thing i change is the sha1 string - nothing else.

Gtk-Gnutella - and the same applies probably to most clients - won't download files you share respectively already own. Maybe that's the reason?

the only thing i change in the queryHit is the sha1 - i change letters and sometimes the whole sha1. It allows me to DL the same file over and over again - just when i double click on the search result with the calculated sha1 it doesn't send me the GET request - only with the sha1 i stated in my msg. Every other sha1 i insert is ok for the clients.

I will now search in FW/LW's code what happens after i double click the file name from the search result - and take it from there. If anyone can help i'll be gratefull.

For what it's worth, the file is badly encoded or recorded.

Accepts my queryHit with the calculated sha1 and asks for the file and i even finish DL, and the file is fine. I don't know what the f#$% is gtk-gnutella's problem with this sha1, but i can't keep hitting my head against that wall (metaphoric wall, of course, i took my pills today!).
So the file is fine - just gtk-gnutella doesn't allow me to give this sha1 for some reason.

Thanks for your always-rapid response, and of course your help.
If i ever will be able to find why gtk-gnutella doesn't accept this sha1 i'll post it.

Are you sure the SHA1 isn't listed in ~/.gtk-gnutella/done.sha1 or ~/.gtk-gnutella/sha1_cache?

earlier?! well, i finally found the done.sha1 file and found SO many occurences of the sha1 i wanted, since i DLded without a sha1 before and it calculated it.

Thanks alot. Now everything is fine, besided me feeling stupid for the time spent on this.

Can't thank you enough - now i can move on to other problems i have here and get on with my life.