0

File names with international characters (UTF-8) are accepted by Sharepoint libraries / OneDrive. However, for Tibetan/Choekey/Dzongkha script, they seem to be saved improperly in the backend, and the characters become somehow indistinguishable from each other once stored.

Make two files:

མགོན་པོ་ཀླུ་སྒྲུབ་ཀྱི་རྣམ་ཐར། ༠༡.txt

མགོན་པོ་ཀླུ་སྒྲུབ་ཀྱི་རྣམ་ཐར། ༠༢.txt

They are different filenames, but the names have the same number of characters. After the first file is uploaded, the second one cannot be, throwing the error "A file with an equivalent name exists." The file names are not the same -- why does SharePoint/OneDrive treat them as "equivalent"?

If the second filename has a different number of characters in it than the first, or is mixed with standard ASCII characters that differ from those in another filename of the same length, the file is accepted for upload without throwing the error.

The error does not apply to other international characters. The following two files upload just fine:

карабкаться.txt

карабкатьяс.txt

Is this a product limitation in the Microsoft cloud storage ecosystem or are there certain settings/alternative encoding to the filename that could be done to make it more acceptable?

The error can be reproduced by anyone (just copy-paste the characters from above into the names of simple dummy files).

2
  • Have you opened a ticket with Microsoft via admin.microsoft.com? This would be the best place to get support for this issue since it may be a product defect. – Trevor Seward Aug 24 '20 at 14:53
  • @TrevorSeward yes the ticket has been opened. I have been supplying them with all the follow-up information they requested also. They can reproduce the problem on their own now and will likely confirm it as a product limitation. I am wondering if any others have experienced this and come up with any workarounds. Or if there are any unicode alternatives that we can tell our users to use to achieve the same script/characters. – SSP Aug 25 '20 at 2:29
0

Microsoft Support indicate that this is a product limitation 'by design'.

After thorough investigation and testing we found that this result is 'By Design'. SPO databases use a different collation model than the client OS, which means file names that are different on a client machine may be treated the same on SPO.
Unfortunately as this is found to be a design limitation, this cannot be raised to fix.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.