[Feature request] Create .torrent and/or magnet hashes mounts them

[markg85]

Hi,

The title is a bit tricky but describing it probably helps in understanding what i'm asking.

What if you could add torrent file or magnet hash in a BTFS mount point where BTFS would handle the "mounting" of these new files automatically?

Here's an example of how such a mount action would look like:

mkdir mnt
btfs mnt
cd mnt

Note that the btfs mnt in this example gets no torrent or magnet.

Let's assume the torrent / magnet content is:

video.mkv
thumbs/1.jpg
thumbs/2.jpg
thumbs/3.jpg

Inside this mnt folder one can then add torrent files or magnet hashes like so:

cd /mnt
cp ~/torrentfile.torrent .
## -- BFTS detects `torrentfile.torrent` and "mounts" it internally --
## torrentfile.torrent mounts as `torrentfile`
cd torrentfile
vlc video.mkv
gwenview thumbs/1.jpg
# or as full path
gwenview /mnt/torrentfile/thumbs/1.jpg

Or with a magnet hash:

cd /mnt
touch "e940a7a57294e4c98f62514b32611e38181b6cae"
## -- BFTS detects `e940a7a57294e4c98f62514b32611e38181b6cae` and "mounts" it internally --
## -- mounts `e940a7a57294e4c98f62514b32611e38181b6cae` as `e940a7a57294e4c98f62514b32611e38181b6cae_data`
cd e940a7a57294e4c98f62514b32611e38181b6cae_data
vlc video.mkv
gwenview thumbs/1.jpg
# or as full path
gwenview /mnt/e940a7a57294e4c98f62514b32611e38181b6cae_data/thumbs/1.jpg

The idea here is that BTFS internally takes care of mounting torrent files and magnet hashes.

What you'd end up with is a filesystem in which you can drop torrent files and magnet hashes which then automatically become browsable as soon as BTFS has downloaded the torrent metadata to present the content hierarchy.

Removing the torrent or magnet hash should remove the "mounted" data too.
The user would only be able to create and remove torrent files or magnet hashes in the root level of the BTFS mount.

I did have a quick look at the code. Currently it seems focused on handing a torrent as it got it as mount argument. So implementing this proposed feature probably is a quite big refactor. I do think it's worth it though as having completely transparent torrent mounting would be super nice to have! As far as i'm aware, a feature like this on a filesystem level doesn't exist. Torrent clients do have this feature somewhat, you can open a torrent/magnet and see what's inside. But that's by no means a filesystem like interaction.

As a cherry on top, this can be neatly integrated into file managers like KDE's Dolphin. There for example it would be possible to add the option to open a torrent. Internally that would add the torrent to the mount point that can handle it and potentially a symlink would be created from that torrent to the user's home folder making it completely transparent from a user point of view.

[markg85]

Since reporting this issue (earlier today) I've been playing with the code to hack in the above.
What i keep hitting up against is the code being very focused on one torrent. It has global variables to handle that one torrent. That logic isn't going to work in a multi-torrent usecase.

Would it be possible to refactor this to be ready for multiple torrents on a technical level?
Functionally it can still work exactly as-is, but it would be ready to implement my above proposal.

[johang]

I prefer to not do this. It would completely change the way this software works.

[markg85]

I prefer to not do this. It would completely change the way this software works.

Yeah, I totally understand!
Thank you for your fs! It's unique and quite cool!