>>9934>copying torrents to IPFSResults can be the outcome of:
(a.) getting a copy of a partially-downloaded torrent - copy to /torrents/by_infohash/${i}.partial in that case
(b.) getting a copy of a fully-downloaded torrent, but the folder contains extra files/folders which aren't part of the torrent
(c.) getting a copy of a fully- or partly-downloaded torrent, but some files/folders have been renamed
Case (a.) example - 44.6%-downloaded where the rest is gone and it has a piece size of 2 MiB:
. torrent? magnet:?xt=urn:btih:0bb67d65df5d995a1e8270c8f6e3fc26a8e244ce&dn=Ponibooru-All-Safe.zip
. where? zb, offline /ipfs/QmWKMmCdUweQxxAcrjvNBsxuygSJX31HWhqNYi64w8Q9ji <- 'ipfs add -w --raw-leaves --chunker=size-1048576 "Ponibooru-All-Safe.zip"'
. size? 82.86-GiB folder /ipfs/QmbLRDDkrYtKEb8RNFK8zXJKSe7XJKBVeesvGezi238JHn
Case (b.) example - has IA-derived files such as "76752CB1198327A3F70211C9B0143C078E9486A5_torrent.txt" (from "76752CB1198327A3F70211C9B0143C078E9486A5.torrent") which helps due to listing the original paths in the folder so you know which files or folders came from the torrent and which didn't:
. torrent? magnet:?xt=urn:btih:76752cb1198327a3f70211c9b0143c078e9486a5
. where? zb, offline /ipfs/QmR8tzekkxjvoGoAWgUjMxWuP3ueARssv3vfFxGdwTJGVF <- 'ipfs add -rHw "40 OMG Sexy Milky Boobs Exposed By Adriana Lima"'
. size? 10.47-MiB folder /ipfs/QmQ1A2PBvAEj8c4C3cvhGgz5Zf5kaFjQTxH1kg1vCBUgoN
Comparison of 100% complete hashtrees:
. BitTorrent: for the data, all SHA1 hashes must match. Otherwise, files and folders can be renamed and extra files or folders can be added to a folder.
.. applies to example infohash of 8327a3...9b0143
. IPFS: for the data, all multihashes must match. If a files or folders is "renamed" then that means it won't match to the original folder CID. If extra files or folders are "added" to a folder, then it also won't match to the original CID.
.. applies to example CID Qm3c...5Zf5
BitTorrent and IPFS both have various settings for chunks/pieces, but not getting into that in the following:
. The idea with BitTorrent is like this: the .torrent file has the original file/folder layout and paths. The save path can have renamed versions of those files and added data. The save path contains the same data insofar as the SHA1s match and it can largely differ beyond that.
. The idea with IPFS is like this: as specified by the CID, this file is exactly this file and that folder is exactly that folder. Any difference like renaming files or adding data to a folder = different folder CID. The save path is basically "$IPFS_PATH/.blocks/" and users are almost always expected to not interact with .data files in .blocks/ as they don't need to (you can rsync them from repo to repo to get more blocks...).
With torrents, the original path(s) can be decoupled with the save path(s). The original layout is contained in a BitTorrent seed file. Therefore, IPFS seems to be a more sane way to contain whatever file(s) and folder(s). Unless you make an effort not to, saved data for torrents has the meaning of "here's these files/folders which may or may not match to the original paths and may or may not have extra data". With torrents, you also must know the infohash that applies to that folder/file: check $HOME/.local/share/data/qBittorrent/BT_backup/*.fastresume for that. Even if you try to keep original and save path one to one, it could be difficult. For example, if you run this -- "rsync -a --info=progress2 /a/trnt/ /b/trnt/" -- and your computer loses power or something, then rsync will leave behind a temp file in the format of ".filename.txt.Blah4" in one of the torrent folders. Another issue is with various platforms like Windows, which doesn't like characters such as ":" in filenames. In that case, you cannot keep it one to one for torrents which contain filenames with ":" or "^" or whatever; not a problem in IPFS.