ttorrent icon indicating copy to clipboard operation
ttorrent copied to clipboard

Serialization no longer changes torrent hash.

Open valdisxp1 opened this issue 3 years ago • 0 comments

Repeatedly serializing and de-serializing no longer changes the torrent hash. This can create hard to debug issues when saving, loading or transmitting TorrentMetadata. "Let's save the torrent. It is saved. But where is it? (I cannot find it by the hash.)"

There are two issues:

  1. Saving whether the torrent is private or not. TorrentSerializer places a info.private=1 only if the torrent is private otherwise it does not include that key. On the other hand, the newer MetadataBuilder would always include that key and put either a 0 or 1 depending if it private or not. According to bep_0027 :

When generating a metainfo file, users denote a torrent as private by including the key-value pair "private=1" in the "info" dict of the torrent's metainfo file

There is nothing about "private=0", so I assume we can omit it like in the serializer. 2. Single file torrents described in a multi-file format. This has a valid use case like giving the file a custom path like in testMultiFileModeWithOneFile. TorrentSerializer treated a single file in multi-file mode a one in single-file mode. It did not have enough information to distinguish between the two case in scenario like in testMultiFileModeWithOneFileSameName where fileName == directoryName. There is a difference between abc and abc/abc. Previously getDirectoryName could also return the file name in single-file mode. Then it should be simply getName.

If you find any value in this pull request please tag it with hacktoberfest-accepted so I get credit towards the https://hacktoberfest.digitalocean.com/ event.

valdisxp1 avatar Oct 09 '20 21:10 valdisxp1