Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
markg85 opened this issue Apr 26, 2024 · 1 comment
Open

Comments

@markg85
Copy link

markg85 commented Apr 26, 2024

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
Copy link
Author

markg85 commented Apr 26, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant