Bug 138615 - Insure Windows wildcards work properly with long paths
Summary: Insure Windows wildcards work properly with long paths
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.2.0.0.alpha0+
Hardware: All Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Commandline
  Show dependency treegraph
 
Reported: 2020-12-02 06:43 UTC by Deb
Modified: 2020-12-06 11:46 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 Deb 2020-12-02 06:43:48 UTC
Description:
In Windows, we must manually handle wildcards like ? and *. We use FindFirstFileW() in loader.cxx to handle the wildcards. FindFirstFileW() may not handle paths over 255 characters unless a \\?\ is prepended. If given an absolute path prepend a \\?\.

Steps to Reproduce:
1.soffice.exe c:\veryLongPath\*.docx
2.
3.

Actual Results:
Long path names do not have their wildcards expanded.

Expected Results:
Long path names have their wildcards expanded.


Reproducible: Always


User Profile Reset: No



Additional Info:
Taken from Mike's comments on https://gerrit.libreoffice.org/c/core/+/106393
Comment 1 Mike Kaganski 2020-12-02 07:03:31 UTC
I would suggest using PathCchCanonicalizeEx for this, with PATHCCH_ENSURE_IS_EXTENDED_LENGTH_PATH flag. It fits perfectly for the task, except conversion of "/" into "\" - it does everything else, like removing "." and "..", making sure the path has the "\\?\" in case when the mask is shorter than 2MAX_PATH, but the found name would be longer ... but the problem is, the function is supported since Windows 8, while our baseline is Windows 7 still.

[1] https://docs.microsoft.com/en-us/windows/win32/api/pathcch/nf-pathcch-pathcchcanonicalizeex
Comment 2 Mike Kaganski 2020-12-02 10:16:28 UTC
(In reply to Mike Kaganski from comment #1)
> but the
> problem is, the function is supported since Windows 8, while our baseline is
> Windows 7 still.

On the other hand, https://stackoverflow.com/questions/57354840/which-dll-has-pathcchappend suggests that the function may be in api-ms-win-core-path-l1-1-0.dll, which is part of UCRT, which we depend on, and which we require on Windows 7. The function is not guarded by any "#if _WIN32_WINNT >= 0x0602" thing in pathcch.h - so maybe it's actually works on Win7 SP1 with UCRT? Could you check?