Created attachment 186961 [details] zip file with 2 screenshots and a document with umlaut in the name to show the bug Files with umlauts (ä, ö, ü, è, ñ, ..-) etc. in the filename or pathname cannot be opened with Open dialog. They can be selected within the dialog but when the open button is pressed the message "Error: (filename) doesn't exist" appears. As I have seen the bug does not affect files with Unicode filenames and also not files with umlauts in the name when they are opened as member resp. entry in the recently used files list. Reproducing the bug: - unpack file "Auprès de ma blonde.odt" from the attached zip file into any folder - open LibreOffice - choose "Open a file" - navigate to the unpacked file "Auprès de ma blonde.odt" and select it - press "Open" - Result: An error message appears (as in "Screenshot 2023-04-27 115640_Message_File_doesnt_exist.jpg") The behavior was reproduced with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9a555d79b3b00793edf1d51a8a7c76b723cc436d CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded but not with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 006b35d50024b1932d84380b5d2fec1f7066bccd CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded Result of bisect: 9e89aab60b9744a309bcd92333b1e01eef9c8aa7 is the first bad commit commit 9e89aab60b9744a309bcd92333b1e01eef9c8aa7 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Sat Apr 22 09:00:45 2023 -0700 source df4255c315f8061fbe7b3771122926589be7dfad source df4255c315f8061fbe7b3771122926589be7dfad instdir/program/fps.dll | Bin 175616 -> 174592 bytes instdir/program/setup.ini | 2 +- instdir/program/version.ini | 2 +- 3 files changed, 2 insertions(+), 2 deletions(-)
If I do an unzip -l on that file I get a 'AuprКs de ma blonde.odt' Much likely the original file name is in some 8-bit code page encoding not matching the file system's encoding (which nowadays except on Windows is usually UTF-8, less some old never-die systems). Of course these names don't match then and asking for one doesn't find the other.
(In reply to Eike Rathke from comment #1) > If I do an unzip -l on that file I get a 'AuprКs de ma blonde.odt' > Much likely the original file name is in some 8-bit code page encoding not > matching the file system's encoding (which nowadays except on Windows is > usually UTF-8, less some old never-die systems). Of course these names don't > match then and asking for one doesn't find the other. I think this is correct: The problem exists only in Windows and affected are file/path names not coded in UTF8 but in 8 bit code with special characters in the range from 0x80 until 0xff. Would it make a difference when I attach a document with the name "Tästdokument.ods" (name coded in 8 bit)?
Created attachment 187037 [details] additional screenshots to show the problem described in Comment 3
An other way to get a document for demonstrate the bug is to create one. Create with LO 7.5 (or LOdev 7.6 with a build date before Sat Apr 22 09:00:45) a new odf document (odf or ods) with any content and save it as e.g. "Tästdokument.ods" or "Tästdokument.odt". Important: The filename contains at least one "german" special character (ä, ö, ü. ß). Precondition: Windows with Locale: de-DE (de_DE); UI: de-DE Other buggy behavior caused by the same commit (also found by bisect: commit 9e89aab60b9744a309bcd92333b1e01eef9c8aa7, Author: Norbert Thiebaud <nthiebaud@gmail.com>, Date: Sat Apr 22 09:00:45 2023 -0700, source df4255c315f8061fbe7b3771122926589be7dfad): Create an odf document as described above but with a younger LOdev 7.6. build (built after the commit time) - with at least one "german" special character (ä, ö, ü. ß) in the filename, save the document and close it. Result: After save the filename is shown wrongly in title bar ("T%E4stdokument.odt" instead of "Tästdokument.odt") and after close also on the Start screen with recently used documents. Maybe this behavior could be reported as a separate bug but because it seems it is caused by the same LO change as the "original" Open problem I think this is not necessary.
(In reply to Stefan_Lange_KA@T-Online.de from comment #3) > Created attachment 187037 [details] > additional screenshots to show the problem described in Comment 3 not Comment 3 but Comment 4
Mike, the bibisection Stefan did points to your commit: commit df4255c315f8061fbe7b3771122926589be7dfad author Mike Kaganski <mike.kaganski@collabora.com> Sat Apr 22 16:12:23 2023 +0200 committer Mike Kaganski <mike.kaganski@collabora.com> Sat Apr 22 17:45:50 2023 +0200 Simplify lcl_getURLFromShellItem And make the URL returned for the item by system to be the preferred result. Reviewed-on: https://gerrit.libreoffice.org/c/core/+/150784 Can you please have a look?
*** This bug has been marked as a duplicate of bug 155176 ***