added new preformatted type to bencode entry

[arvidn]

to support carrying a verbatim copy of an already bencoded subtree. This is to support saving torrents in resume data and create_torrent based on existing torrents, in order to preseve key order

[sledgehammer999]

How am I supposed to test this? I compiled and run it but it still mutates the hash. Do you want me to use some specific function?

[arvidn]

hm.. I thought it would fix that case. the internal entry hierarchy in create_torrent is supposed to preserve the info-dict from the torrent, when passing in a torrent_handle to it (with this patch). and bencode() is supposed to support include such pre-encoded sections.

would you mind stepping into the create_torrent constructor to make sure the metadata buffer is preserved verbatim?

the other place where this could be broken is in bencode(). You do use the bencode() function in libtorrent to encode the entry, right?

The unit test passes, so I'm a bit surprised it didn't work. I may have overlooked some code path that you're hitting.

[sledgehammer999]

Sadly I cannot test further tonight. However I noticed a slight change from my previous test. I don't know if it is your patch or that I was using RC_1_0.

When the metadata are fetched from DHT we save them in our folder as hash.torrent and also creating hash.fastresume. Without your patch this hash was the mutated one. With your patch it is the initial hash. However, upon restart and loading those files libtorrent shows the mutated hash instead. Could the loading functions mutate it instead? We use this signature to load it: torrent_info(std::string const& filename, error_code& ec, int flags = 0);

[sledgehammer999]

Well I just checked again. The initially saved torrent is mutated. The info fields are rearranged. ie the length field gets rearranged above the name field.

[arvidn]

basically any time the torrent gets turned into an entry, it will get reordered, so if your load path includes a decode step into an entry, that's a problem. However, there are plenty of alternatives for loading. bdecode_node is probably the best one. It's faster, uses less memory and doesn't reorder fields.

[sledgehammer999]

As I said it is written mutated to disk(create_torrent -> bencode). Also bdecode_node isn't available in RC_1_0.

[codecov-io]

Current coverage is 68.34%

Merging #698 into RC_1_1 will increase coverage by +<.01%

1. 14 files (not in diff) in src were modified. more
   • Misses -8
   • Hits +9
2. 2 files (not in diff) in include/libtorrent were modified. more
   • Misses -3
   • Hits +3
3. File src/torrent.cpp was modified. more
   • Misses -9
   • Partials 0
   • Hits +9

@@             RC_1_1       #698   diff @@
==========================================
  Files           264        264          
  Lines         42467      42504    +37   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits          29003      29046    +43   
+ Misses        13464      13458     -6   
  Partials          0          0          

Powered by Codecov. Last updated by f065cac...e6e24bf

[arvidn]

I added a unit test and discovered a bug in create_torrent. it should work now.

[sledgehammer999]

Great! Now it seems to work!!! Please backport to RC_1_0 if possible.

[sledgehammer999]

Did you mean integers ? Same typo(?) in the following tests too.

[sledgehammer999]

And reading up on bencode from wikipedia, I realize that we face this problem because of some broken torrent creator program/library. Dictionaries are supposed to be sorted alphabetically but that broken implementation doesn't do that. Too bad the metadata don't record the torrent creator.