[Libreoffice-bugs] [Bug 125995] New: C locale is currently broken for file handling

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=125995

            Bug ID: 125995
           Summary: C locale is currently broken for file handling
           Product: LibreOffice
           Version: 6.4.0.0.alpha0+ Master
          Hardware: All
                OS: Linux (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: LibreOffice
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: glogow at fbihome.de

Description:
This is the "extension" of bug 125971.

Something in the local file URL handling is currently broken when you use the C
locale, at least on all unix backends. I can't test MacOS and Windows, but
since I suspect an error in the URL handling with regard to the current locale
setting, at least MacOS might be affected too. Has Windows some equivalent of C
locale?

Steps to Reproduce:
1. Have a unicode / UTF8 file system (that's standard I guess)
2. Have a file name with non-ASCII characters (łąka.png - 'LC_ALL=C ls -b' will
show the correct UTF8 encoding \305\202\304\205ka.png)
3. Start LO with LANG=C / LC_ALL=C
4. Open the file
5. Export the file

Actual Results:
1. The file picker for "gen" shows the wrong file names. kde5 and gtk3 are
fine.
2. After opening, the window title has the file name with a wrong encoding.
3. The recent file list has the file name with wrong encoding (which actually
works!)
4. The save dialog has the wrong default name.

5. Saving the file will generate the right file name only for gen.
For gen the wrong default on save is consequently correct and it'll ask before
overwriting the existing opened file. kde5 and gtk3 will write a new file with
a - now really wrong name.

The saved file name for gtk3 and kde5 is:
\303\205\302\202\303\204\302\205ka.png. 

That's the same encoded name I would generate for the fix for bug 125971 via

OUString aNewURL =
uri::ExternalUriReferenceTranslator::create(m_xContext)->translateToInternal(toOUString(aURL.toEncoded()));

But this is actually some double encoding, because aURL.toEncoded() is already
the correctly encoded UTF8, which LO expects. And it's probably the origin of
most of the bug. 

FWIW this is the only encoding variant LO currently accepts from either kde5 or
the  gtk3 file picker.

Expected Results:
The correct filename is used everywhere, where it's now wrong in the "Actual
Results".


Reproducible: Always


User Profile Reset: No



Additional Info:

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20190618/6c6b7c2d/attachment.html>