"Don't add torrent's name to path" option

[JohnFlowerful]

Requesting a feature like that of rutorrent/rtorrent:

This would be useful for cross-seeding torrents. For example: You have two torrent for 'lots of files'; torrent a and torrent b. Both torrents contain the same content. However, torrent a wants to create a directory called 'lots.of.files' while torrent b wants to create the directory 'lots_of_files'. To cross-seed in this situation, you would need to edit either torrent a's or torrent b's torrent file to match the directories. With the "Don't add torrent's name to path" option, this would not be a problem. Users would not need to edit torrent files which in turn means cross-seeding with trackers that check torrent hashes would be possible.

[fuyukaidesu]

By default it's gonna result in: ~/Downloads/a/lots.of.files/... ~/Downloads/b/lots_of_files/...

Is that wrong ? What do you mean ?

[JohnFlowerful]

torrent a would create ~/Downloads/lots.of.files/ torrent b would create ~/Downloads/lots_of_files/ With the "Don't add torrent's name to path" feature, one would download torrent a and then add + recheck torrent b with the files from torrent a.

I hope that makes sense >_>

[fuyukaidesu]

Closed for not making sense.

[nyanpasu]

@fuyukaidesu He wants an option to not result in

~/Downloads/a/lots.of.files/... ~/Downloads/b/lots_of_files/...

Instead, he wants to see something like:

~/Downloads/lots.of.files/... ~/Downloads/lots_of_files/...

Could you please think about it again.

[JohnFlowerful]

That's not what I want.

The end result would be only one directory for both torrents, even though they create a different directory each. One torrent would be added to the client normally, while the other would be added with the "Don't add torrent's name to path" option ticked/selected.

[infoburp]

Just read this, it's not hard to understand, really, just badly explained. @JohnFlowerful I'm looking at you.

He wants to download the same torrent from two sources, and have them both point at the same folder.

[fuyukaidesu]

If they are the same torrents, they should have the same name, and the same files, in that case by default, no new folder is created, the only thing to do is to merge the trackers in the existing transfer.

[infoburp]

Well no, they might have the same files in a differently named folder.

I don't know if this has a name as a theory, but a tutor of mine once told me:

No matter how stupid an action seems, eventually a user will attempt it.

[bobbintb]

I know it's an old topic but since it's still open, I get what he's saying. It's been a feature I've been looking for forever until I found it in rtorrent. It's essential for cross seeding. Say you download a torrent from one tracker and it downloads "mymovie1.mov", ""mymovie2.mov", and "mymovie3.mov". Now you want to cross seed that on a different tracker but the person that uploaded it to that tracker decided to put all those files in a folder "my_movies" before creating the torrent. Even though those files are the same files, they are in a folder so if you try to cross seed the data the files will not be found and will not pass a hash check because the folder structure is different.

[IGI-111]

That's a protocol limitation, I'm not aware of a way to seed by individual file hash on bittorent, and even less so to resolve individual files through the DHT.

IPFS exists for that very reason though, and it even works on chunks, not just files.

[benwaffle]

lol gtorrent

[bobbintb]

I dunno, just clarifying the issue. I do know rtorrent has that feature and I use it all the time so there obviously is a way.

[nyanpasu]

I think it's possible to modify the file mappings of a torrent file.

libtorrent-rasterbar appears to support it.

[IGI-111]

I guess you can take advantage of that to seed your files with and without a top level folder, but it's a pretty ugly hack. Would definitely be nice if you could have individual hashing for every file.

But at least it's a solution for that problem indeed.

[nyanpasu]

What is ugly about it?

You can choose which pieces you want to seed, but that's a different feature.

Files are just mappings to pieces.

[IGI-111]

Essentially, at that point you're just seeding two separate torrent hashes linked to the same chunks of data. You just created a whole other metadata set just to convey a lack of top level folder.

Maybe it's just me, but that's damn ugly.

If you really wanted to avoid tracker misses, you'd also want to seed for torrents that aren't yours, but contain the same files (and with the number of release teams that just copy shit from the scene that does happen quite a lot) but to do that you'd have to create yet another amount of metadata.

The central problem here is that bittorrent doesn't do file level hashing.

So yeah what you propose should work and it should work well for this precise issue, but it's very much a workaround for protocol limitations.

_{And now I realize I'm ranting.}

[bobbintb]

Just a note, it might be rutorrent that does this and not rtorrent.

[Merlincool]

This is very important feature and could help if there is a cli way to do it.

[nyanpasu]

Well, looking back at it, I change withdraw my opinion on it. @IGI-111 and @fuyukaidesu was right, it's pretty hacky.

Fix your torrents manually. You can also achieve the requested functionality using hardlinks. It's not a concern of your bittorrent client to handle that use case, although simple. Where do we draw the line? What if two torrents have the same set of files, but have a totally directory layout? Do we account for that too? If not, why this but not that?

Not gonna support it :^)