Download it now!
Bug 46434 - Errors opening files via IPC with 8-bit encoding of file names
Summary: Errors opening files via IPC with 8-bit encoding of file names
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Localization (show other bugs)
Version:
(earliest affected)
3.5.0 release
Hardware: Other Linux (All)
: medium minor
Assignee: Stephan Bergmann
URL:
Whiteboard: target:3.6.0
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-22 01:29 UTC by Alex Prokofiev
Modified: 2012-03-08 12:32 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Correctly transform abs. paths to URLs (739 bytes, text/plain)
2012-02-22 01:29 UTC, Alex Prokofiev
Details
Correctly decode arguments when file encoding is not UTF8 (643 bytes, text/plain)
2012-02-22 01:33 UTC, Alex Prokofiev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Prokofiev 2012-02-22 01:29:54 UTC
Created attachment 57440 [details]
Correctly transform abs. paths to URLs

When LibreOffice is already running, opening new files with
national characters in name fails when local filename encoding is not UTF8.

Steps to reproduce:
(assume, that locale is ru_RU.KOI8-R and filenames are encoded in KOI8-R)
1. Create file пример.odt
2. Start lowriter
3a. Run libreoffice --writer пример.odt
This produces an error in started instance 'file <utf bytes> not found'
3b. Run libreoffice --writer /abs/path/to/пример.odt
This makes no response at all.

In both cases file пример.odt should be opened.

Attached patches correct this problems.
Comment 1 Alex Prokofiev 2012-02-22 01:33:29 UTC
Created attachment 57441 [details]
Correctly decode arguments when file encoding is not UTF8

The xTranslator->translateToInternal expects input to be in local encoding,
while oosplash converts all arguments to UTF prior to encoding.
Using INetURLObject::translateToInternal transforms URL correctly.
Comment 2 Andras Timar 2012-02-23 08:04:34 UTC
Thanks for the patch Alex, can you please confirm that you submitted this under MPL/LGPLv3+?
Comment 3 Alex Prokofiev 2012-02-23 21:24:58 UTC
(In reply to comment #2)
> Thanks for the patch Alex, can you please confirm that you submitted this under
> MPL/LGPLv3+?

Yes, of course. The patches are under MPL/LGPLv3+
Comment 4 Stephan Bergmann 2012-02-29 01:34:42 UTC
The real problem is that CommandLineArgs::ParseCommandLine_Impl (desktop/source/app/cmdlineargs.cxx) traditionally assumes URL arguments to be in "external" (cf. documentation in udkapi/com/sun/star/uri/XExternalUriReferenceTranslator.idl) form while send_args (desktop/unx/source/start.c) erroneously sends them in "internal" form.  In some cases, INetURLObject::translateToInternal is resilient to input that is already in "internal" form, but that is more good luck than proper design.
Comment 5 Not Assigned 2012-02-29 02:53:30 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cf4416a68fb68f36cf9065c6d08d14dd22637b24

fdo#46434: No need to turn arguments into absolute file URLs when sending
Comment 6 Stephan Bergmann 2012-02-29 03:14:42 UTC
Alex, can you check whether the commit mentioned in comment 5 solves the problem for you?
Comment 7 Alex Prokofiev 2012-02-29 03:21:01 UTC
I've just tried to remove code block as in commit and russian (KOI8-R) file names don't work - no response at all.

ASCII files, though, open with absolute and relative file paths.

(previous patch with INetUrlObj was also removed).
Comment 8 Alex Prokofiev 2012-02-29 03:30:28 UTC
I can insert some debug code and post results if required.
Comment 9 Not Assigned 2012-02-29 06:14:13 UTC
Stephan Bergmann committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8bbf048085066b8e95256e7d59d7ddd89465d4e7

fdo#46434: Always send command line arguments as UTF-8
Comment 10 Stephan Bergmann 2012-02-29 06:26:41 UTC
Alex, I hope the second commit (see comment 9) fixes it now.
Comment 11 Alex Prokofiev 2012-03-01 04:37:30 UTC
Yes, with latest patch everything works as expected. Tried both
KOI8-R and UTF-8 encodings and both relative and abs. paths.

Thanks!