Don't download file

[RandyDavis]

I downloaded a torrent with many files in it. I also found another torrent that was different (names slightly changed) but had the same files. So I tried to split them and say don't download these on one and download these on the other. Anyway these are very slow and I noticed that the ones I skipped had pieces still downloading. Its a 4 meg download for each piece and there are 5 of them downloading pieces for skipped files. I've tried to delete these but can't. Anyone know how to fix this?

Thanks,

Randy

[Ultima]

Nothing you can do about it. There is no such thing as a "file" in BitTorrent, only pieces. Pieces can belong to multiple files, and µTorrent HAS to download the entire piece to verify that it is not corrupt, even if it contains data for a piece you explicitly told µTorrent not to download.

[fluffylon]

There may be no such thing as a "file" in the bittorrent protocol, but there sure is in the program implementing that protocol.

Besides, I thought the diskio.use_partfile was basically intended to fix this.

"diskio.use_partfile is used to store data that is downloaded of files that you marked as "Do not download." This is necessary to prevent the file from being allocated. It stores the parts of the files that come with a piece, since µTorrent must download and save the entire piece, which can include data for files you didn't want to download. Generally, you should avoid using this in conjunction with compact allocation."

[Ultima]

What's your point? The client still has to follow protocol, so pieces are STILL the most important unit of data, WHATEVER the client can do. And no, the partfile feature was intended to store unwanted data that still needs to be downloaded. It doesn't prevent the files from being touched as long as at least one piece that contains data for that file is unfinished.

[fluffylon]

Following the protocol has nothing to do with the specifics of how the client manages things locally. In your own words: "there is no such thing as a file in bittorrent".

My point is that it can be very frustrating when utorrent meddles with files that you want it to leave alone. I would much prefer if it stored the information for those 2 (max) pieces elsewhere, say in a "partfile". I assume the partfile fills this purpose if the skipped file doesn't exist in the first place? I'd simply like it to behave that way regardless of whether the skipped file exists or not. But perhaps I still don't understand how the partfile is supposed to function? You seem to be saying one thing in this thread and another (which agrees with my understanding) in the other thread. It doesn't really matter though -- my point remains and there's no reason why the problem can't be solved programmatically one way or the other.

The fundamental point is this: I think the program would be better off behaving the way I've described (really leaving skipped files alone), and you seem to either dislike that behaviour or be under the impression that it's impossible to implement. If it's the former then I'd appreciate it if you could tell me right now as I'm just wasting my time then. I have a feeling I might be wasting my time anyway as you're not the coder, are you?

[Ultima]

No, I'm not the coder, only ludde is

My point is, the file is incomplete. If so, then at least one piece is incomplete that belongs to that file. Even if you mark the file to be skipped, the incomplete piece stands, and it could very well be shared with another file. If the other file that shares the piece is not skipped, and µTorrent needs to touch the piece, it needs exclusive lock on any file that has data in the piece.

I'm not seeing where I was inconsistent with my description of the partfile, but the point is that the partfile is used to store unwanted data that needs to be downloaded for a piece to be considered complete, and to prevent the unwanted files from being allocated on disk. If part of the data already exists and/or the file it belongs to is already allocated on disk, the data won't be written to the partfile, since it'd already be too late for the partfile's job to kick in in the first place.

The way I see it is -- if you don't want µTorrent to touch the file, then stop the torrent, move the file somewhere else, mark the file as skipped, and start the torrent again. Not sure if a force re-check needs to be fitted before the starting of the torrent, but yeah, that's the general gist of the idea. As long as the file is still in there, and it's sharing data with another piece µTorrent needs to write to, then IMHO, it's fully within µTorrent's rights to touch the file and place a lock on it for precaution's sake. If µTorrent needs to lock the file, then it's trying to write to it, and if it's trying to write to it, then it's incomplete (AFAIK). µTorrent needs to prevent data corruption from leaking into the swarm, and if it isn't allowed to touch a piece that it needs to write to, the piece is going to be considered corrupt the next time you start µTorrent up.

Edit: A further thought... if you want it to not touch the (incomplete) skipped file, and only touch the partfile, then how is µTorrent supposed to know when to access the partfile for blocks and when to access the skipped file for blocks, when it needs to upload data from the hypothetically questionable piece(s)?