Download it now!
Bug 130216 - Safe mode: Show user profile fails to open the folder
Summary: Safe mode: Show user profile fails to open the folder
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All Windows (All)
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:7.0.0 target:6.4.1
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-27 12:06 UTC by Xisco Faulí
Modified: 2020-02-05 07:24 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2020-01-27 12:06:48 UTC
Steps to reproduce:
1. Launch LibreOffice
2. Go to Help - Restart in Safe mode
3. Advanced - Show user profile

Error displayed: (com.sun.star.lang.IllegalArgumentException) { { { Message = "XSystemShellExecute.execute, SHGetFileInfoW(C:\\Program Files\\Libreoffice3.3\\LibreOffice 6.4.0.2\\program\\..\\user) failed", Context = (com.sun.star.uno.XInterface) @0 } }, ArgumentPosition = (short) 0 }

Reproduced in

Versión: 6.4.0.2 (x86)
Id. de compilación: 08d19fecdc7a2298d051e19cfdb7c35544855fc3
Subprocs. CPU: 2; SO: Windows 6.1 Service Pack 1 Build 7601; Repres. IU: predet.; VCL: win; 
Configuración regional: es-ES (es_ES); Idioma de IU: es-ES
Calc: threaded
Comment 1 Xisco Faulí 2020-01-27 12:19:22 UTC
it fails with a build installed through SI-GUI < https://wiki.documentfoundation.org/SI-GUI > and with the bisect repositories but not with a build installed using the .msi file

The problem started to happen after https://cgit.freedesktop.org/libreoffice/core/commit/?id=d59ec4cd1660410fa1b18c50d2d83b1417a82ddc

@Stephan, would you consider this an issue?
Comment 2 Stephan Bergmann 2020-01-27 12:49:01 UTC
(In reply to Xisco Faulí from comment #0)
> Steps to reproduce:
> 1. Launch LibreOffice
> 2. Go to Help - Restart in Safe mode
> 3. Advanced - Show user profile
> 
> Error displayed: (com.sun.star.lang.IllegalArgumentException) { { { Message
> = "XSystemShellExecute.execute, SHGetFileInfoW(C:\\Program
> Files\\Libreoffice3.3\\LibreOffice 6.4.0.2\\program\\..\\user) failed",

I assume LO is indeed installed at "C:\Program Files\LibreOffice3.3\LibreOffice 6.4.0.2"?
What is the full content of the line starting "UserInstallation=" in "C:\Program Files\LibreOffice3.3\LibreOffice 6.4.0.2\program\bootstrap.ini"?
Comment 3 Xisco Faulí 2020-01-27 12:55:24 UTC
(In reply to Stephan Bergmann from comment #2)
> (In reply to Xisco Faulí from comment #0)
> > Steps to reproduce:
> > 1. Launch LibreOffice
> > 2. Go to Help - Restart in Safe mode
> > 3. Advanced - Show user profile
> > 
> > Error displayed: (com.sun.star.lang.IllegalArgumentException) { { { Message
> > = "XSystemShellExecute.execute, SHGetFileInfoW(C:\\Program
> > Files\\Libreoffice3.3\\LibreOffice 6.4.0.2\\program\\..\\user) failed",
> 
> I assume LO is indeed installed at "C:\Program
> Files\LibreOffice3.3\LibreOffice 6.4.0.2"?

Yes, it's there

> What is the full content of the line starting "UserInstallation=" in
> "C:\Program Files\LibreOffice3.3\LibreOffice 6.4.0.2\program\bootstrap.ini"?

UserInstallation=$ORIGIN/..

( same in the bisect repository )
it's

UserInstallation=$SYSUSERCONFIG/LibreOffice/4

in the installation that works
Comment 4 Stephan Bergmann 2020-01-27 14:32:19 UTC
So looks like the call to

> if (SHGetFileInfoW(
>         o3tl::toW(pathname.getStr()), 0, &info, sizeof info, SHGFI_ATTRIBUTES)
>     == 0)

in CSysShExec::execute at <https://cgit.freedesktop.org/libreoffice/core/tree/shell/source/win32/SysShExec.cxx?id=d59ec4cd1660410fa1b18c50d2d83b1417a82ddc#n334> fails with zero when pathname contains a ".." segment.

Mike, any idea whether that is actually the case (<https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shgetfileinfow> doesn't appear to mention something like that), and whether there is a workaround?
Comment 5 Mike Kaganski 2020-01-27 21:02:52 UTC
(In reply to Stephan Bergmann from comment #4)
> So looks like the call to
> 
> > if (SHGetFileInfoW(
> >         o3tl::toW(pathname.getStr()), 0, &info, sizeof info, SHGFI_ATTRIBUTES)
> >     == 0)
> 
> in CSysShExec::execute at
> <https://cgit.freedesktop.org/libreoffice/core/tree/shell/source/win32/
> SysShExec.cxx?id=d59ec4cd1660410fa1b18c50d2d83b1417a82ddc#n334> fails with
> zero when pathname contains a ".." segment.
> 
> Mike, any idea whether that is actually the case
> (<https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-
> shgetfileinfow> doesn't appear to mention something like that), and whether
> there is a workaround?

I tried to debug this, and indeed this is the case; SHGetFileInfoW internally calls SHParseDisplayName, which fails for this path, and also at that moment, GetLastError() returns ERROR_MORE_DATA (a leftover from some internal WinAPI).

I found out that calling PathResolve(pathWithTwoDots, nullptr, PRF_VERIFYEXISTS | PRF_REQUIREABSOLUTE) puts corrected path into the pathWithTwoDots. I suppose that could be a workaround for now... (but PathResolve has a nice-looking warning :-( [1])

[1] https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-pathresolve
Comment 6 Mike Kaganski 2020-01-27 22:32:16 UTC
https://gerrit.libreoffice.org/c/core/+/87565
Comment 7 Commit Notification 2020-01-28 07:15:22 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/f772ccb8008c4e9429982a226eab3341da1cdeed

tdf#130216: normalize paths with .. segments

It will be available in 6.5.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 8 Xisco Faulí 2020-01-30 13:13:50 UTC
Verified in

Version: 7.0.0.0.alpha0+ (x64)
Build ID: ee9a15422561dfae0ae259c1641695f6c5c41388
CPU threads: 16; OS: Windows 6.3 Build 9600; UI render: default; VCL: win; 
Locale: en-GB (en_GB); UI-Language: en-US
Calc: threaded

@Mike, thanks for fixing this issue!!
Comment 9 Commit Notification 2020-02-04 10:06:37 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/fc043d38c256243fb782cc48e7708feaeabba4ae

tdf#130216: normalize paths with .. segments

It will be available in 6.4.1.

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.