qBittorrent official forums

why store it in a temp space when you can just flush it out to disk

The 'temp space', as you put it IS on disk, but if YOU delete the file/folder that contains the "unwanted" pieces it is no longer 'on disk'. Then, if a peer requests one of those pieces that the resume data declares that your client has and your client cannot locate it (because it is not where it should be) so will throw an error and/or force a recheck which results in the client having to re-download the MISSING piece that you deleted.

If you do not intend to seed the torrent EVER AGAIN, you can do ANYTHING you like with the .unwanted folder or the PartFilennn.dat HOWEVER if you continue to seed or want to reload the task at ANY time in the future using BitTorrent whether it is qBittorrent, Vuze, uTorrent, BitTorrent, Deluge, Transmission, KTorrent, rTorrent, MLDonkey, Halite, etc. etc. YOU ABSOLUTELY, 100% MUST HAVE those "unwanted" pieces so the payload that you possess can be served to other peers.

Also if your client has a different method of handling cross file pieces those missing parts of the payload WILL start downloading when you restart the task.

Also if your client has a different method of handling cross file pieces those missing parts of the payload WILL start downloading when you restart the task

seems so inefficient anyways!!!

if you need to keep the cross-file pieces in a temporary space, so be it, but why not complete the single files AND FORCE A RECHECK LATER?

IT'S LIKE I DOWNLOADED THE FULL COMPLEMENT OF SAY 5 FILES, BUT THEN I DELETED 3 FILES; WHEN I RE-SEED, I HAVE THE COMPLETE TWO FILES ALREADY!!

But you do NOT have ALL the pieces that constitute the payload, because they have been deleted or not dowloaded. You have some files certainly, but not the binary data that BitTorrent clients need.

Can I suggest you read  this, this and  this to further your understanding of how the BitTorrent protocol actually works.

An example, file 1 occupies 1.5 blocks of space.  Since bittorrent protocol requires *complete* blocks to seed, the bittorrent client must somehow store the 0.5 block from file 2 (not selected for download)  uTorrent has it's method, qbit uses the unwanted folder to store this "partial file" which is actually the partial block ***required*** to be able to seed file 1.  If you delete file 2's "partial" data you have deleted part of the data that the client needs to seed File 1.  Read the links ciaobaby gave you.  It's not about what "files" where downloaded, but what *blocks* are needed to fully seed what you did download.

AM saying there must be a better way to handle the crossfile pieces.....

If I downloaded 5 files and then deleted 3 files, OBVIOUSLY i dont have the complete torrent, BUT i have some data and that is in COMPLETE files.

When the client does a FORCE recheck it should read the crossfile pieces from the COMPLETE files and recache that !!

OR it can download it own crossfile pieces and reinserted back into the files if they dont match....seems more elegant to me, but I aint a coder LOL

Ok wait a minute, if the client says the files are 100% downloaded, is it fully 100% downloaded?
As an end user, i really dont need to know about the PAYLOAD LOL Thats for the client to decide

All I need to know is if the file on my desktop is 100% complete (even if its only 1/2 a block of what the client needs to seed, store the other half block in a temp file if you need to)

PS. why do i get the feeling the protocol itself doesnt deal or detect the file sizes or hash? So the Client cannot check for the hash of the files themselves?

The WHOLE point revolves around YOUR idea that you can DELETE the "unwanted" file or folder and have the client carry on as if NOTHING has happened. THAT is never, ever going to happen. You HAVE to leave the .unwanted folder or the "PartFile" alone, no deleting, no moving, no recycling, no renaming, NOTHING. Leave it alone, ignore it, pretend it does not exist.

PS. why do i get the feeling the protocol itself doesnt deal or detect the file sizes or hash? So the Client cannot check for the hash of the files themselves?

Right time to appear patronising methinks.
It can and does ... WHEN YOU CREATE THE TORRENT then it stores the sequential piece number AND the hash sum value for that piece number in the meta data. (meta being derived from the Greek for  'after' or 'beyond' so is "information that goes beyond the actual data")

After that clients HAVE to use the piece hash sums IN THE META DATA to VERIFY that the pieces stored on or in the recipient peer(s) memory or storage medium  are EXACTLY the same as they were WHEN CREATED, therefore  have not been corrupted in transit or altered in any way that may affect the data integrity. That is why it is called a "hash CHECK" or a "Force re-CHECK" not a hash SUM.

Did you actually read the documents I linked to? Because, judging from this "the hash of the files themselves" you still seem to have the miscomprehension that it is 'files' that are being hash summed, it is not, the hash is of the individual pieces, which may contain part of a file, all of a file or parts of more than one file.

the client should check the separate files themselves, and flush out the complete files irrespective of the "blocks" that torrent uses....

As i said, torrent has evolved into multiple file UNITS, except you cannot complete individual files unless you download the whole shebang!!!

You haven't listened to any of the information being presented.  Only the complete blocks for the files selected are downloaded.  If you delete files you lose data that is required to have complete blocks.  It's how bittorrent works. Get over it.  Done with this thread.

the client should check the separate files themselves, and flush out the complete files irrespective of the "blocks" that torrent uses....

Well all I can say is:


If you want a download client that does that ..... ..... ....

ciaobaby wrote:

the client should check the separate files themselves, and flush out the complete files irrespective of the "blocks" that torrent uses....

Well all I can say is:


If you want a download client that does that ..... ..... ....

Am still waiting!!! The request is out there

Get with 2014 already !!! Or are we in the caves still?

You are not listening or maybe not comprehending fully and given that you missed the post in large bold lettering that was intended to drive the message home, the BitTorrent protocol is NEVER going to work the way you think it should. in fact it was SPECIFICALLY developed to reduce the problems that can occur during downloading of large, monolithic files as a single entity over unreliable networks, which is what you apparently wish to go back to.

Get with 2014 already !!! Or are we in the caves still?

The simple fact is that YOU should NOT be using BitTorrent protocol clients, the method on downloading does not suit YOUR requirements. So to save you the arduous task of  researching . ...

http://www.bearshare.com/
http://www.emule-project.net/
http://www.oldversion.com/windows/winmx/
http://edonkey2000.en.softonic.com/

None of which use the BitTorrent protocol which you appear to despise.

Failing that:

I suggest spotify, iTunes, eMusic or Amazon.

some people just dont seem to take "constructive" criticism too well?

there is a limitation in the protocol, the question is can it be worked around. I dont care what its designed to do, I only care if it can be used to do what i need it to do....

One of the solution is to find another protocol or a single torrent with the single file that that I need and complete it that way....It's NOT elegant solution, so by discussion, I am hoping the client developers can find a way around it.

there is a limitation in the protocol, the question is can it be worked around.

There is no "workaround" it works how it works and that is the end of it!

I dont care what its designed to do, I only care if it can be used to do what i need it to do....

In response to that comment can I most disrespectfully say that, in the context of this conversation you are an idiot!

Will you be going on to object to the fact that HTTP (also a protocol) doesn't allow YOU to stop and start downloads whenever you want, so should be changed??

Or that FTP doesn't allow you to browse web pages or you cannot read emails over NTP (Network Time Protocol).

The BT protocol is designed to do what it does and YOU cannot change that because it doesn't suit YOU. If you don't like how it works ....

expletive deleted

USE

SOMETHING

ELSE!

Protocols are what they are, "created for a SPECIFIC purpose". The word 'protocol' means "A set or rules or procedures for use in a given situation" and if the protocol in use doesn't fit the conditions ... you need a different protocol.

If you need to remove or tighten a wheel nut ... using a hammer will not do the job successfully, so are you going to learn from this discourse and accept the fact that you are simply using the wrong tool or will you be declaring that we are all wrong and BitTorrent is flawed when it is  you that is using it incorrectly or inappropriately.
Personally I am happy to be proven incorrect regarding my opinions or assertions, because it means that I have learnt something