Verifying local data fails on files with some non-ASCII characters in their names

[Golffies]

Context:

• torrent includes files having Polish (non-ASCII) characters in their names
• torrent file has been created with Transmission 2.84 on a host running OS X and imported to Transmission 2.52 on a server running Debian.
• the torrent has to be seeded by Transmission 2.52, not leeched.
• content files have then been copied to the mass storage of the server running Transmission 2.52, not using transmission itself to locally create the files.

Actual behaviour:

Before starting to seed, when verifying the local files with Transmission 2.52, verification fails on nearly each file whose name contains at least one Polish (non-ASCII) character. However, this is not true for all Polish characters. Character "ł" does not disturb Transmission 2.52. See attached screenshot.

Expected behaviour:

Verification of the local content files with Transmission 2.52 is expected to be successful as these files are the exact copy of those which the torrent file was created on.

Attachment:

Screenshot of Transmission web UI showing part of the files verified properly and part of them whom verification failed.

[Golffies]

Screenshot of Transmission Web Interface

[mike.dld]

Hopefully you realize that 2.52 is a 3+ years old version and no one is going to fix it. Please install 2.82 or 2.84 (I know those are available in Debian repositories; building from source is always an option too) and see if issue persists. Reopen if necessary.

[Golffies]

We upgraded to Transmission 2.84 on the Debian server. The issue persists.

[mike.dld]

If you let Transmission download those missing files, are they created alongside the existing ones or overwrite them? What I'm trying to understand is could it be possible that filenames encoding was somehow broken during the files transfer.

[mike.dld]

And since you are mentioning Mac, could it be related to #5616?

[mike.dld]

@Golffies, anything to add?..

[Golffies]

Hi Mike,

after further investigating, I have to apologise for having reported a bug which was not related to transmission but to the file management web app which we used. That old version of Ajaxplorer was translating diacritics without any warning to the user, then actually changing the name of the files ! Looking at the list of files in the repository from a shell, it was not possible to see any difference (see the attached screenshot and test text file : Zażółć gęślą jaźń.png and Zażółć gęślą jaźń.txt).

Sorry for my mistake. Cheers.

[mike.dld]

The files didn't make it through for some reason. Please reattach for the sake of completeness.

[Golffies]

Sounds like a bug in Trac prevents to attach the files Zażółć gęślą jaźń.png and Zażółć gęślą jaźń.txt but let it to be done for the files Zazolc gesla jazn.png and Zazolc gesla jazn.txt. Additionally, I failed to report the very bug, as the url I have been directed to do so failed to open. Anyway, this is another matter.

[Golffies]

BTW, there is a strong chance that the whole mess is related to NFD (Mac) vs NFC (Linux) Unicode character encoding standards, as you pointed out when directing me to bug #5616. You were right. I had no idea that such an issue may arise between platforms, all of them being "unicode compliant". At that point, my best guess is that Ajaxplorer wrote on the Debian host files' names following NFD standard, when rsync transcoded files' name from NFD to NFC during the copy process.

At first glance, it looked like Ajaxplorer made some changes to the files' name, which is likely a wrong statement. It actually failed to convert from NFD to NFC.

Those few words added "for the sake of completeness" as you said. :-)