Files with forbidden characters can't be downloaded

[koberulz]

What is the issue?

If a torrent contains a file with a forbidden character in the filename, it throws an error and fails to download the torrent. Other clients will substitute forbidden characters with, say, underscores.

For example, "Chapter One: Introduction.pdf" is valid in Linux, and a torrent could be created for this file. But downloaded in Transmission for Windows, it will simply create a file named "Chapter One" with no file extension, then say the file cannot be downloaded due to a file system limitation. Other clients will instead download the file, successfully, as "Chapter One_ Introduction.pdf".

Which application of Transmission?

Qt app on Windows

Which version of Transmission?

4.0.5

[killemov]

For completeness: Naming Files, Paths, and Namespaces

AFAIK Windows has the most restrictions on file names. Still kind of weird that these are still OS-based instead of filesystem-based.

[Coeur]

I recall I fixed it in #6187. (Transmission 4.1.0 dev/nightlies)
Win32 nightlies can be downloaded at https://build.transmissionbt.com/job/trunk-win32/

We do have this same documentation link in our code, killemov:

transmission/libtransmission/torrent-files.cc

Lines 383 to 387 in 2e7448c

	// https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file
	// Use any character in the current code page for a name, including Unicode
	// characters and characters in the extended character set (128–255),
	// except for the following:
	[[nodiscard, maybe_unused]] auto constexpr isWin32ReservedChar(unsigned char ch) noexcept

[killemov]

Any such limitations for macOS?

Huh, the date on the referenced article is 02/26/2024, but I guess that means last updated. Also the mentioned GitHub file reference works, but the commit reference leads to some typo in documentation.

[Coeur]

Any such limitations for macOS?

macOS was my predilection system for investigation. No, macOS on APFS or HFS+ is not affected and behaves as a Unix-like system (only / is forbidden in filenames, which we treat as folder separators). But having an external disk/partition on NTFS with macFUSE + NTFS-3G and asking macOS Transmission to download on it is unsupported (behavior is undefined).

but the commit reference leads to some typo in documentation.

I now changed to a different commit to make it less awkward.

[Coeur]

According to #6801, it happens in Transmission 4.1.0 too. Reopening.
I don't have a Windows computer, so I can't analysis this further myself.

[tearfur]

This is not an OS-specific bug, and it is not related with the sanitization code itself. PR already up for the fix.