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
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?
(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"?
(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
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?
(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
https://gerrit.libreoffice.org/c/core/+/87565
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.
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!!
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.