Bug 98343 - FILEOPEN: can't open files in path of more than 260 chars
Summary: FILEOPEN: can't open files in path of more than 260 chars
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.0.5.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.3.0
Keywords:
Depends on:
Blocks: File-Opening
  Show dependency treegraph
 
Reported: 2016-03-02 10:04 UTC by Eneko Lacunza
Modified: 2018-12-17 11:25 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Error window (5.69 KB, image/png)
2016-03-11 09:49 UTC, Eneko Lacunza
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eneko Lacunza 2016-03-02 10:04:04 UTC
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.
Comment 1 Eneko Lacunza 2016-03-02 10:04:53 UTC
We tested on Windows 7 Pro 64 bits and Windows Server 2012r2 Std 64bits.
Comment 2 Buovjaga 2016-03-10 10:08:54 UTC
Other software are able to open such files?
Comment 3 Eneko Lacunza 2016-03-10 10:27:50 UTC
Yes, I tried with Adobe Acrobat for example; no problems.
Comment 4 raal 2016-03-10 14:13:01 UTC
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).
Comment 5 V Stuart Foote 2016-03-10 15:24:42 UTC
(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.
Comment 6 Eneko Lacunza 2016-03-11 08:33:51 UTC
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
Comment 7 raal 2016-03-11 08:52:59 UTC
(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?
Comment 8 Eneko Lacunza 2016-03-11 09:49:18 UTC
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
Comment 9 Eneko Lacunza 2016-03-11 09:50:23 UTC
I tried to open this very file with notepad from Windows explorer and works perfectly (garbage shown though ;) ).
Comment 10 tommy27 2016-10-10 19:34:19 UTC Comment hidden (obsolete)
Comment 11 Eneko Lacunza 2016-10-13 14:21:57 UTC
Just tested with 5.2.2.2 x86 and issue persists.

Thanks
Comment 12 Aron Budea 2017-09-13 14:39:15 UTC
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?
Comment 14 Aron Budea 2018-12-07 01:20:54 UTC
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.
Comment 15 Eneko Lacunza 2018-12-10 14:30:59 UTC
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.
Comment 16 Aron Budea 2018-12-14 06:26:27 UTC
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
Comment 17 Eneko Lacunza 2018-12-14 08:47:58 UTC
I don't have a build environment to build and test modified binaries; but can test if someone can produce those...
Comment 18 Mike Kaganski 2018-12-14 11:55:52 UTC
https://gerrit.libreoffice.org/65158
Comment 19 Commit Notification 2018-12-14 14:31:31 UTC
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.
Comment 20 Commit Notification 2018-12-15 15:30:43 UTC
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.
Comment 21 Eneko Lacunza 2018-12-17 11:22:22 UTC
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?
Comment 22 Eneko Lacunza 2018-12-17 11:25:17 UTC
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!!!