[Feature Request] Relocate / Rename Single Files

[Yogi1]

Would be great to be able to relocate single files and / or to rename them.

[maya923]

I'm all for relocating single files, but renaming them will change the hash of the torrent and then there will be all sorts of mess-ups.

[pyroscope]

What has the storage path to do with any piece or info hashes? Answer: nothing.

[maya923]

I didn't say the storage path will change anything, I said renaming the actual files will change the hash.

[pyroscope]

No it won't.

[maya923]

In my experience that has not been the case, if you wish to share how it is done, please do to help others in a similar predicament.

[Yogi1]

Well I don't think it's a philosophical predicament. It's just the way it works. Just take some programme to read a torrent metainfofile (.torrent) and you will see what information is there in, which also served (maybe not all but at least a big part) to calculate the hash sum.

Now that has nothing to do with the storage path and the name you give to the files (afterwards). As example in uTorrent you are having all these extra infos kept in the resume.dat file (which you can also open with a bencode editor). So pyroscope statement is perfectly correct and yours above simply wrong. It's always good to know before to state wrongly. ;)

[pyroscope]

Anyway, this is yet another dupe of #245, #167, and #19.

[Yogi1]

Absolutely correct. Thank you pyroscope!
That being said it looks like a very old suggestion (real need!) that is around since almost 4 years. With the recent experiences I did, linked with diacritics problems, there are certain torrents I simply cannot load (seed) within rtorrent. It made me quite mad :(( I spent many hours trying all, even with symlinks but without success. I abandoned and will probably have to seed some torrent over another client, which of course is totally frustrating. Actually I would not even have migrated my thousands of torrents to rtorrent if I would have been aware of this limitation.

[chros73]

there are certain torrents I simply cannot load (seed) within rtorrent

Example files?

[maya923]

Again, I'm not even talking about the storage path, I am talking about the actual file name itself and the information stored in the torrent file. I've used torrenteditor.com and easily have seen the hash change. Would you like a screenshot? A video perhaps? Don't berate me; if you have a solution, share it. No one is born knowing everything.

[pyroscope]

Nobody except you talks about changing the metafile itself, because that cannot work, ever. With any client. Unless you then do a new upload with the changed infohash.

[Yogi1]

Example files?
@chros73

I have several actually but let's use this one as example (I just show the problematic word with diacritics)
Torrent file name: Misérables.torrent
Appearing in ruTorrent as: Mis?rables.torrent
Appearing in rTorrent as: Mis ables.torrent (note the r also missing)
Hash re-checking simply impossible, whatever the way I tried. Either rTorrent is simply never starting the hashing (verification) process or it's simply stuck at the very beginning.
I read several reports of people having the same type of problem with diacritics. I checked all I could about the locale of my system and everything seems ok at that level (UTF-8). I also tried to add "encoding.add = UTF-8" or "encoding = UTF-8" in my rtorrent.rc file but that did not change anything at all.

[pyroscope]

Use lstor --raw … on your metafile – Unicode isn't all that simple when it comes to diacritics.

[Yogi1]

Just installed what was needed. Can you do something with this ?
'name': 'Les Mis\xe9rables ...
It's a private tracker, I don't want to disclose sensitive information publicly.

[pyroscope]

It means someone stupid created a metafile with Latin-1 or CP1252 encoding.

Quoting BEP-3: “All strings in a .torrent file that contains text must be UTF-8 encoded.”

GIGO applies.

PS: Since it's the root name, you can possibly fix it using http://rtorrent-docs.readthedocs.io/en/latest/cmd-ref.html#term-d-directory-base-set (unless there's files with non-ascii codepoints in them)

[Yogi1]

It means someone stupid created a metafile with Latin-1 or CP1252 encoding.

Yes that seems very plausible. He probably just used a client which did it that way. Still I'm puzzled by the fact that on the tracker's website the "é" is appearing like it should. qBittorrent is displaying it as "Mis_rables" on my Linux system and creating the corresponding folder name. So it's a cosmetic problem but at least it's working. Why can't rtorrent simply deal with it too, no matter how the "é" finally would be displayed? If I try to autolad it it's not loading at all. When I try manually I get an error "Failed to add torrent" in the rutorrent log.

About your PS suggestion, well I had a look but it's going quite in more complex scripting topics. I noticed that my .rtorrent.rc is totally different than the one you advocate to use. I have probably an old version which is still around everywhere. One example just to make it clear:

port_range = XXX in my config file
network.port_range.set = XXX in the suggested config file

Honestly (sorry for my ignorance) I'm presently not even sure if the "d.directory_base.set = ‹hash›, ‹path› ≫ 0" command must be placed in the .rtorrent.rc file or not.

[James-E-A]

renaming the actual files will change the hash.

> No it won't.
In my experience that has not been the case,
if you wish to share how it is done, please do

@maya923, this feature proposes merely providing an interface to client-side overrides via libtorrent's rename_file; they don't change the filename in the torrent, merely the name-as-stored in the physical, local filesystem. This can be used when the user wants to name/store the files differently than the original torrent-creator did, without losing access to the existing swarm.

Don't berate me; if you have a solution, share it.

This is an uncontroversial ability of torrent clients. For example, Deluge (the other popular libtorrent interface) has supported this feature since twelve years ago: deluge-torrent@87f3e1e: you just right-click the file and choose "Rename"; it doesn't change the infohash.

(Anecdotally, nikil claims in issue #167 that "[this] is a common operation in almost every other torrent client".)

[James-E-A]

It means someone stupid created a metafile with Latin-1 or CP1252 encoding.

That is certainly disconcerting, from a technical perspective...

I wonder if there's any precedent for torrent clients automatically "gracefully" handling these by e.g., saving the files to a UTF-8 converted local file name?

---

ETA: it looks like pyroscope is (mostly) right; this is a duplicate of #245 and #167. @rakshasa, consider closing this to consolidate discussion at #167?

[James-E-A]

I wonder if there's any precedent for torrent clients automatically "gracefully" handling these by e.g., saving the files to a UTF-8 converted local file name?

A reasonable algorithm for such might be:

• Try to decode the filename bytestring as a UTF-8 sequence of Unicode characters
  - Was it interpreted without errors?
  • If so: use that sequence as the filename.
  • If not: refuse to load the file until a valid encoding is specified,
    then rename_file to map all applicable filenames to their UTF-8 equivalents before initializing the torrent

[pyroscope]

Some people seem to conflate librorrent-rasterbar and *-rakshasa here, btw. No, they're not the same.

[James-E-A]

Some people seem to conflate librorrent-rasterbar and *-rakshasa here, btw. No, they're not the same.

To be clear: I was not confused while writing my post. rakshasa is the owner of this repo (to close duplicate issues, which is what the @-mention was about), and the musings on robust-handling of screwed-up metafile encoding definitely belong at the client software layer rather than the libtorrent layer.