Bug 861668

Summary: Cannot open Russian filenames
Product: [Fedora] Fedora Reporter: Tobias Mueller <fedora-bugs>
Component: libreofficeAssignee: Caolan McNamara <caolanm>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 17CC: caolanm, dtardon, erack, ltinkl, mstahl, sbergman
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-10-01 03:27:41 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
screenshot of the problem none

Description Tobias Mueller 2012-09-29 17:28:05 EDT
Created attachment 619213 [details]
screenshot of the problem

Description of problem:
I have a .xls file from a Russian Windows system but libreoffice can't open it :(

The filename could be
In [43]: f1 = '\xd1%88\xd0\xba.2.xls'

In [44]: open('/tmp/'+f1, 'w')
Out[44]: <open file '/tmp/�%88к.2.xls', mode 'w' at 0x1112c00>

Opening with LibreOffice fails:
$ libreoffice *2.xls
produces an error message, that the file could not be opened.

Turns out, that the \xd1 is the minimal test case. Opening '\xd1.4.xls' fails.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:
I expected it to open the file. Despite the fact that the filename is not proper utf-8 but probably windows-1252 or so.

Additional info:
Comment 1 Stephan Bergmann 2012-10-01 03:27:41 EDT
This is an unfortunate consequence of a long-standing internal design decision in LibreOffice/OpenOffice.org, namely to internally represent all pathnames as file URLs with UTF-8 encoded payload.  In a locale like UTF-8, where \xD1 does not represent a valid character, there is currently no way for LibreOffice to transport the pathname intact from the user to the system interface.  Due to the massive impact any changes to this would have, a fix in the foreseeable future is unlikely.

As a workaround, you can rename the file before opening, or try to start soffice from a locale where \xD1 /is/ a valid character, like

  LC_ALL=C soffice ...