This issue involves complex path handling across multiple APIs and requires careful architectural planning.
The issue involves widespread problems with `std::filesystem::path` handling on Windows, particularly with non-ASCII paths, affecting multiple APIs. It requires a coordinated solution across the codebase, possibly involving a new wrapper API. Blockers include the need for careful planning and consensus among maintainers to avoid introducing new issues.
v24.1.0
Microsoft Windows NT 10.0.19045.0 x64
No response
Couldn't find a tracking issue for this one.
There are places in the source that handle std::filesystem::path objects, and on Windows, this involves conversion between UTF-8 strings and wchar-based paths. This can lead to path corruption, as previously discussed.
One example of this is #56049, which has an open PR to fix this specific usage. However, #58764 has just been reported, which affects a completely different area of the API. There are other examples of usage elsewhere in the source.
It feels like this probably needs a library-wide approach – even if not removing std::filesystem::path entirely as previously discussed, then at least some sort of internal wrapper API to abstract out potential footguns.
Claim this issue to let others know you're working on it. You'll earn 35 points when you complete it!