file: support directory listing on Windows - #22577
hunterinvariants wants to merge 1 commit into
Conversation
|
One Windows job was cancelled at its 15-minute job timeout while the test suite was running. Configure, build and build-tests completed successfully, and test 3203 passes in the other Windows jobs. I cannot rerun the upstream workflow; could someone rerun the cancelled job? |
There was a problem hiding this comment.
Pull request overview
Adds desktop Windows support for file:// directory listings while preserving Unicode and long-path handling.
Changes:
- Detects directories when Windows file opening fails.
- Enumerates entries with
FindFirstFile. - Enables Windows testing, including Unicode filenames.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
lib/file.c |
Implements Windows directory detection and listing. |
lib/curlx/fopen.c |
Adds a UTF-8-aware FindFirstFile wrapper. |
lib/curlx/fopen.h |
Declares the new wrapper. |
tests/data/test3203 |
Enables Windows and Unicode directory-listing coverage. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
0497e90 to
60aa66a
Compare
|
The remaining MSVC job failed before running tests because the certificate generator could not find a working The same job reached the test suite in the previous run, and all other 212 checks passed. This appears to be a runner/tooling issue. I cannot rerun the upstream workflow; could someone rerun the failed job? |
|
How is the existing file: directory support lacking on Windows?
|
|
Builds with |
|
Was this previous limitation documented anywhere that needs an update too now? |
| if(result) { | ||
| size_t pathlen = strlen(path); | ||
|
|
||
| /* Some Windows CRT variants reject trailing directory separators. */ |
There was a problem hiding this comment.
Do you know more about which variants? Can we maybe include details?
E.g., is UCRT affected?
There was a problem hiding this comment.
The reproduced failures are the x86 and x64 MinGW-w64 ANSI builds, both linked to msvcrt.dll. The Unicode build is also linked to msvcrt.dll, but uses the wide-character path and passes. So the evidence is specific to narrow stat() with MSVCRT. I have not tested UCRT and updated the comment to avoid implying that it is affected.
Can't remember seeing this one before. Seems safe to ignore unless it's reoccuring. edit: another one: https://github.com/curl/curl/actions/runs/31784619882/job/94717691027 |
| } | ||
|
|
||
| #if defined(_WIN32) && !defined(CURL_WINDOWS_UWP) | ||
| static CURLcode file_win32_list(struct Curl_easy *data, const char *path) |
There was a problem hiding this comment.
| static CURLcode file_win32_list(struct Curl_easy *data, const char *path) | |
| static CURLcode win32_file_list(struct Curl_easy *data, const char *path) |
minor name suggestion to keep win32 in the front to match rest of code.
There was a problem hiding this comment.
Renamed as suggested.
60aa66a to
47e8182
Compare
|
Yes. |
47e8182 to
5d2f2e6
Compare
In GitHub runner image windows-2025-vs2026 v20260810.198.2, the default Perl binary changed from MSYS2 to Strawberry. The reason is that the MSYS2 installation not longer has Perl preinstalled. As seen in CMake configuration: ```diff - -- Found Perl: C:/a/_temp/msys64/usr/bin/perl.exe (found version "5.42.2") + -- Found Perl: C:/Strawberry/perl/bin/perl.exe (found version "5.42.0") ``` curl's Perl scripts require an MSYS2 Perl. Fix by installing it manually in this one job. Symptom was `gencert.pl` no longer finding openssl.exe: ``` Missing or broken 'openssl' tool. openssl 1.0.2+ is required. ``` Then the script hanging while trying to trace it. Also: - add distinct error message and list PATH elements if openssl is not found via `gencert.pl`. - tried falling back to Git for Windows Perl, which caused the test step to either hang or run too slowly to fit the time slot. Refs: actions/runner-images#14541 https://github.com/actions/runner-images/releases/tag/win25-vs2026%2F20260810.198 Bug: #22577 (comment) Bug: #22577 (comment) Closes #22580
|
Rebasing on master will fix the MSVC job. It turned out to be a real, non-flaky fallout due to a breaking GH runner image update. Ref: #22580 |
5d2f2e6 to
1dfdb53
Compare
|
Thanks! |
Implement
file://directory listings on desktop Windows usingFindFirstFile.The new internal curlx wrapper keeps the existing Unicode and extended-path handling. Directory entries are returned as UTF-8 and dot-prefixed entries remain excluded, matching the existing implementation on other platforms.
Test 3203 is enabled on Windows and covers a non-ASCII filename in Unicode builds.
Verified with MinGW x64 Unicode, x64 ANSI and x86 ANSI builds; manual directory matrices on Windows 11 and Windows Server 2025; a long Unicode path on Windows 11; and the Linux non-flaky suite (1602 tests).
Addresses #6379.