This problem happens double-click on Windows file explorer, and also using the Open File dialog inside Writer. Tested using a Windows share. If the file has long enough path (259+ chars?), Writer is unable to open it and reports a "<wrong_path> does not exist" dialog. "wrong_path" is the UNC path to the file, but the server name has its first char removed, seems UNC path building has a bug ¿? Can reproduce this easily, ask any question you need.
We tested on Windows 7 Pro 64 bits and Windows Server 2012r2 Std 64bits.
Other software are able to open such files?
Yes, I tried with Adobe Acrobat for example; no problems.
https://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx Maximum Path Length Limitation In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. Not sure if LO's bug, for example I can not copy file into directory long path with Windows Explorer (win7).
(In reply to Eneko Lacunza from comment #0) > This problem happens double-click on Windows file explorer, and also using > the Open File dialog inside Writer. Tested using a Windows share. > Was that the OS Windows explorer dialog, or had you enabled internal LibreOffice Open/Save dialogs from Tools -> Options -> General: checkbox "Use LibreOffice Dialogs" Also, build details for the LibreOffice install? Simply clip from the Help -> About LibreOffice dialog. Thanks.
Windows can in fact use PATHs longer than 260 chars, using unicode paths, and LO is trying to use them (they start with "\\?\"). Problem is first server char is lost. Error message shows path starting "\\?\UNC\erver\..." but it is wrong, should be "\\?\UNC\server\..." Build details: --- Versión: 5.0.5.2 Id. de compilación: 55b006a02d247b5f7215fc6ea0fde844b30035b3 Configuración regional: es-ES (es_ES) --- It was the Windows OS explorer dialog, but I tried with LibreOffice dialog as per your instructions, and the same error appears. I can see path has one non-ascii char (Ó), maybe that's the problem?. I tested putting more non-ascii chars in the file name, but the same error remains (no difference in lost chars in server name) Thanks
(In reply to Eneko Lacunza from comment #6) > Windows can in fact use PATHs longer than 260 chars, using unicode paths, > and LO is trying to use them (they start with "\\?\"). Problem is first > server char is lost. > > Error message shows path starting "\\?\UNC\erver\..." but it is wrong, > should be "\\?\UNC\server\..." > Could you attach error message and write full correct path?
Created attachment 123490 [details] Error window Correct path should be: \\SERVAGURAIN1\agurain-urretxu\testlibreofficebug\SISTEMA CALIDAD\Sistema integrado pruebalibreoffice XX.xX.12\4 PRODUCCIÓN\7.5. TRAZABILIDAD Y RETIRADA PRODUCTO\Simulacro retirada de producto\libreoffice test\Acta Comite de crisis Simulacro 01.01.2015.odt OR in unicode: \\?\UNC\SERVAGURAIN1\agurain-urretxu\testlibreofficebug\SISTEMA CALIDAD\Sistema integrado pruebalibreoffice XX.xX.12\4 PRODUCCIÓN\7.5. TRAZABILIDAD Y RETIRADA PRODUCTO\Simulacro retirada de producto\libreoffice test\Acta Comite de crisis Simulacro 01.01.2015.odt
I tried to open this very file with notepad from Windows explorer and works perfectly (garbage shown though ;) ).
please retest with LibO 5.1.5 or 5.2.2 and tell if issue persists
Just tested with 5.2.2.2 x86 and issue persists. Thanks
Reproduced using a 6.0 daily build (2017-09-11_06:28:48, ffeb750163909e15ee0dd2d16f8030bf08e66eae). It has to be a network share, for local paths it seems to work, right?
https://opengrok.libreoffice.org/xref/core/sal/osl/w32/file_url.cxx?r=e6f4779d#701 https://opengrok.libreoffice.org/xref/core/sal/osl/w32/file_url.cxx?r=e6f4779d#713
I tried reproducing this again, but for some reason now the long path elements are replaced with an 8.3 shortened version, and the bug doesn't occur. Eg. in a path similar to comment 8's, "4 PRODUCCIÓN" becomes "4PRODU~1". Surely this depends on something else as well, I wonder what.
I tried with LibreOffice 5.2 and also with 6.1.3.2 x64, and continue to reproduce the issue on Windows 2012r2 (dind't test in other systems). I have tried clicking from Windows file manager and also from LibreOffice's open dialog. Windows is Spanish / Spain.
Thanks for retesting, Eneko. I still couldn't figure out what else it depends on, because for me for long paths the path segments are substituted with their 8.3 variant, which doesn't cause an error. Comment 5 from V Stuart gave me a hint, though, and I tried with LO dialogs. The setting can currently be found in expert configuration: set UseSystemFileDialog to false. With that I can simply reproduce this bug by navigating a long Windows share path. Getting to a level too deep gives the same error, with the share's first character being cut off. himajin100000's code pointer is also spot on, this line is copying the path incorrectly, cutting off the first character: rtl_uString_newFromStr_WithLength( &strSuffix, aBuf + 2, nNewLen - 2 ); https://opengrok.libreoffice.org/xref/core/sal/osl/w32/file_url.cxx?r=ab9b67bb#699 However, the problem might actually be in GetCaseCorrectPathName(...) call, which cuts starting "\\\\" (technically two backslashes) to "\\" (a single backslash), if this wasn't the case, the previously mentioned code would be fine: https://opengrok.libreoffice.org/xref/core/sal/osl/w32/file_url.cxx?r=ab9b67bb#682
I don't have a build environment to build and test modified binaries; but can test if someone can produce those...
https://gerrit.libreoffice.org/65158
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/12e878d3b5e8a59079811c36b7c89e588266dd0e%5E%21 tdf#98343: ensure PathRemoveFileSpec does not remove UNC's "\\" It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/e0def896eb9b32f95cb7b00afb92421ee51b8281%5E%21 tdf#98343 follow-up: don't fail on UNC prefixes It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I tried with build https://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/current/libo-master64~2018-12-17_03.47.50_LibreOfficeDev_6.3.0.0.alpha0_Win_x64.msi but it still doesn't work. Should I try with some later build?
Sorry, I didn't realize the build didn't replace the 6.1.x version. The build is able to open the file correctly, thanks a lot!!!