ignoring padding files

[roytam1]

The padding files from BitComet 0.85 are annoying. Hope uTorrent can support paddinf files so that they won't download to harddisk.

Thanks.

[DreadWingKnight]

How's about getting the torrent makers to have a clue and stop using bitcomet to make torrents?

It's the better option.

[dAbReAkA]

BitComet 0.87 seems to be creating them too..

.. and when we started filtering torrents with such padding files to be uploaded, all of them uploaders are changing to utorrent now..

yet another reason to ban bitvomit..

[Ultima]

There is absolutely NO reason why µTorrent should have to support stupid things like inserting padded NULL files just because BitComet is being retarded.

[Firon]

No reason to support something that's broken.

[HIyaalll]

I entered this site to request this feature.

"no reason to support somethings that's broken".. Than I assume you won't support windows in the future aswell??

But anywho, it WOULD be nice to us users if uTorrent didn't waste time and space on downloading something that can, by defenition, be assumed to be a lot of nil:s.. even if I agree that bitcomet shouldn't mess with the format which was intentionally created to not waste space... It's not even a big programming consern.. should take less than half a kb in machinecode to recognize the files and just asume that all the blocks in it are nils, rather than saving them anywhere.

[cynixx3]

I agree supporting broken is stupid but why download broken too. Is that what your saying hiyaalll?

[HIyaalll]

stupid and stupid to support broken.. what I am saying is "if you can make broken work, with very little extra effort.. why not?"

But it's still kind of what I'm saying.... What I'm saying is: (I might be wrong) The .torrent file contains several checksums for the individual blocks in the torrent.. Those blocks can be really large, and for the practicality of downloading those blocks are broken down into smaller blocks (which can be downloaded individually from different clients.. or- as I suggest in case of padding files- ignored).. For the torrent program to be able to us the checksum to check if the contents of a block is correct it needs all the small parts of it, but as we already know the content of the small blocks that make out the padding files, the easiest would be to just ignore those files, assume they are filled with nils and run the checksum check on the remainder.

I don't know why bitcomet thinks that adding a lot of empty files is a good idea, I can only assume it is to make the "do not download this file" function a tad more efficiant as the client don't need to mess with any temporary files to store the beginnings or endings of files that you do not wish to download "thanks" to the padding files.

and again.. it is not much programming effort, but when one downloads a file with.. like thousands of small files and the torrent have been created in bitcomet.. I tend to get somewhat annoyed (with the person who created the torrent and with Bitcomet), and a very small adendum to uTorrent could help us a long way.

[martix]

Because people get annoyed and stop using said broken stuff... If you make a workaround you lose that.

[Switeck]

It's the same reason uTorrent doesn't support the "DDoS attack" (on the trackers) form of UDP tracker links. There are proposals to make UDP tracker links a little more manageable and standardized. If/when those at least reach a nearly finalized form, uTorrent probably will support them.

[Ultima]

I don't know why bitcomet thinks that adding a lot of empty files is a good idea

It's because the client isn't only a BitTorrent client, and so it has features specific to it that can't have shared edge pieces -- but why should they force it upon other BitTorrent clients that don't have or care about whatever functionality it is that they decided to implement? If they wanted, they could just as easily have created a new key in the .torrent file metainfo that only BitComet reads. Sure, it's probably a bit less convenient for them, but who cares? It's their feature, let them trouble themselves -- don't bother other clients. But no, they decided to "cleverly" name the padding files in such a way that basically advocates the idea that BitComet is an "upgrade." BitComet got multi-protocol sourcing all wrong. Shareaza manages it without such obnoxious consequences.

FYI, this was never a question of effort or difficulty in implementation. Padding files can be faked in such a way that they force a torrent to never be completed if the client decides to ignore padding files. Just because a file is called "_____PADDING_DOWNGRADE_TO_BITVOMIT_____" doesn't necessarily mean it was not a real file with non-null data that actually existed on the .torrent file creator's disk. Such a poorly-thought-out hack for the files key with all of its dumb drawbacks does not deserve to be implemented anywhere else but in a client like BitComet. The one upshot is that it (supposedly) isn't enabled by default anymore.

Frankly, I'm not surprised I see so many users jumping ship from BitComet and switching clients -- even to BitSpirit. My suggestion to you: find different, non-BitComet-created sources for your torrenting needs.