I need to populate a tree control with torrent's content structure. My code looks like:
std::shared_ptr<lt::torrent_info> torrentInfo;
const lt::file_storage& fileStorage = m_torrentInfo->files();
const lt::index_range<lt::file_index_t>& fileRange = fileStorage.file_range();
for (const auto& index : fileRange) {
const std::string& filePath = fileStorage.file_path(index);
// add new item
}
Concider the following content of the torrent:
Root folder
|- File1
|- File2
|- Folder1
|- File3
|- File4
|- Folder2
|- Folder3
| |- File5
| |- File6
|- Folder4
| |- File7
|- File8
Is it guaranteed that iterating file_storage as I do, I will get the following effects:
File3 and File4 would appear one after other (may be not preserving original order);File5 and File6) and (File1 and File2);File7 and File8 is undefined (I mean which one will appear first).I suppose it to be true because somewhere in documentation it was said that when you retreiving download progress for files with torrentHandle.file_progress(lt::torrent_handle::piece_granularity); you will get the vector of progresses in the exactly same order as in file_storage, so it seems that files have to be stored in some predicted permanent way. Thus, one should be able to store any files data for example in vector in the order it was populated consequently while iterating file_storage.
Or, may be it should be done in entirely different way?
Files have an order in the .torrent file. That's the order you iterate over the files and that's the order file_progress() reports progress for files.
Keep in mind that there may be "pad files". i.e. files that only contain zeroes that are not stored on disk and generally not interesting to users.
It's not clear what "preserving original order" means. Files in directories are not ordered. .torrent creation tool may chose to order files in the .torrent any way they like.
UPDATE:
In v2 torrents (and v1-v2 hybrid torrents), the file structure is deterministic. Files and directories are ordered per path-element. The ordering is byte-wise and names are UTF-8 encoded.