ttorrent
ttorrent copied to clipboard
Serialization no longer changes torrent hash.
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:
-
Saving whether the torrent is private or not.
TorrentSerializer
places ainfo.private=1
only if the torrent is private otherwise it does not include that key. On the other hand, the newerMetadataBuilder
would always include that key and put either a0
or1
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.