option to leave non-portable torrent filenames as-is

[LaserEyess]

OS: Arch Linux 5.7.4-arch-1
Transmission: transmission-daemon 3.00 (bb6b5a062e)

When a torrent with a top level directory such as This : Torrent is added to transmission 2.94, it saves it to the download directory as This : Torrent. The new default behavior in 3.00 is to find and replace illegal Windows characters such as :. However, when upgrading an already working torrent to 3.00, Transmission changes the search path to This _ Torrent but does not change the actual path on the disk, leading to no data being found.

After a quick mv 'This : Torrent' 'This _ Torrent' and reverifying the data in Transmission 3.00 everything works as expected.

Transmission should not rename torrent paths at all on non-Windows OSes. There is no reason to needlessly restrict valid filenames.

[strpkg]

Same issue on macOS 10.13 -

Folders and files with ":", "?", and leading/trailing spaces - that were recognized with no issues on 2.94 - are no longer recognized on 3.00. Instead, the following message shows up in the torrent inspector:

No data found! Ensure your drives are connected or use "Move Data File To…". To re-download, remove the torrent and re-add it.

The manual way to fix this is to strip the leading/trailing spaces and replace ":" and "?" with underscores in all of the affected file and directory names.

Would be nice if the file/dir names were changed automatically during first launch after upgrade from 2.xx to 3.

[sfan5]

Would be nice if the file/dir names were changed automatically during first launch after upgrade from 2.xx to 3.

Absolutely not, the user must be consulted first before doing that.
Also: I use and interact with Transmission solely from Linux systems and should not be subject to stupid filename restriction designed for Windows.

By the way the offending commit is 99033b0

[anohren]

stupid filename restriction

Interesting. In what way is the restriction stupid?

[LaserEyess]

The only operating system this is a concern on is Windows. The characters used in those filenames are perfectly valid on every reasonable operating system. So transmission should definitely not enforce this on the client side for non-Windows OSes.

[anohren]

Oh, yes, I understand that argument, but I was wondering why exactly Windows' restriction was stupid. Reading again I realize that "stupid filename restriction designed for Windows" might refer to the restriction in Transmission, and not the restriction present in Windows... If so, I misunderstood.

[LaserEyess]

This is definitely about what transmission is doing, not Windows. However, Windows is also stupid for this, but that's an entirely separate discussion.

[skorasaurus]

I'm also experiencing this on Ubuntu 20.04.

[mikedld]

The fact that upgrading to 3.00 requires manual actions (files renaming) is a defect.

The fact that Transmission has hardened its filename requirements is not; you're only saying it's stupid because you're (probably) not storing data on a network share managed by who knows which operating system. There's also BEP-3 which clearly states that the names in torrent metainfo are merely a suggestion:

The name key maps to a UTF-8 encoded string which is the suggested name to save the file (or directory) as. It is purely advisory.

I get your frustration but let's not change the topic here.

[LaserEyess]

I would still prefer an option to turn on these filename restrictions. Personally, I do not deal with any situations where torrent data would be stored on windows. If transmission is renaming my files on my disk to cater to Windows I do not think that's right. You're right that the bug is for not renaming the files but if that is your position then I will open a new feature request for an option to specifically not rename files to cater to Windows.

[ckerr]

I would still prefer an option to turn on these filename restrictions

I can't think of many realistic situations where people would want to change this setting. It seems like most people would want it to 'just work' and not think about it.

If someone wants to make a PR to filter filename characters based on the given OS' limitations, rather than unconditionally using the least common denominator of all OSes, I'd be happy to consider that PR for the next release

[ckerr]

See also: #2695 and #1272

[ckerr]

Related: #1700, #4693. These all have the same root cause so I'm tempted to close the other two as duplicates, but it might be better to leave them open for discoverability. 🤷‍♂️