Bug 138615 - Insure Windows wildcards work properly with long paths
Summary: Insure Windows wildcards work properly with long paths
Status: RESOLVED FIXED
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: Mike Kaganski
URL:
Whiteboard: target:25.8.0
Keywords:
Depends on:
Blocks: Commandline
  Show dependency treegraph
 
Reported: 2020-12-02 06:43 UTC by Deb
Modified: 2024-12-08 15:13 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?
Comment 3 QA Administrators 2022-12-07 03:22:28 UTC Comment hidden (obsolete)
Comment 4 QA Administrators 2024-12-07 03:13:45 UTC Comment hidden (obsolete)
Comment 5 Mike Kaganski 2024-12-07 20:59:13 UTC
Today the support for Windows 7 was discontinued in LibreOffice in commit b664c08a6d1096d279437c883e55735a0c431ac8; it's time to review this.
Comment 6 Commit Notification 2024-12-08 15:13:18 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

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

tdf#138615: canonicalize the paths with wildcards, to process long paths

It will be available in 25.8.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.