Opened 8 years ago
#11112 new Bug report
filename comparison and file transfer logic don't match when filename has diacritics
Reported by: | Toni Mäki-Leppilampi | Owned by: | |
---|---|---|---|
Priority: | high | Component: | FileZilla Client |
Keywords: | diacritic, hfs+, utf-8 | Cc: | |
Component version: | 3.23.0.2 | Operating system type: | OS X |
Operating system version: | 10.11.6 |
Description
When I have a filename that has diacritics separated in the HFS+ manner (e.g. ä becomes a¨) I am able to upload complete folders of files to a remote system (Linux www 4.4.0-36-generic #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux) via sftp so that in the process the files end up as diacritics combined to the remote system filesystem (/dev/vda1 on / type ext4 (rw,noatime,errors=remount-ro,data=ordered)).
Now, if I wish to enter into that folder, and having updated locally some files, I want to just attempt an upload on all files and select "overwrite if newer than target", It just happens that FileZilla correctly compares the filenames when determining whether it should ask me about what to do with the files with (virtually) identical filenames (a¨ on local HFS+ == ä on remote ext4). But, after that, it copies the files with diacritics uncombined this time, leaving duplicates with virtually identical filenames.
I digged a little further: if I then try to copy the file with combined diacritical marks (copying filenames to textwrangler document verified which one was which) from the remote side to local, filezilla shows two files on local directory like on remote side, but when you remove either of them, both get deleted (meaning maybe that there was only one file after all or then deleting local files function behaves inconsistently?). I really need this one fixed, please.