Skip to content

fix: support paths longer than MAX_PATH on Windows - #446

Open
abhijeet117 wants to merge 1 commit into
Stebalien:masterfrom
abhijeet117:fix/windows-long-paths
Open

abhijeet117 wants to merge 1 commit into
Stebalien:masterfrom
abhijeet117:fix/windows-long-paths

Conversation

@abhijeet117

Copy link
Copy Markdown

Summary

On Windows, creating a NamedTempFile at a path beyond the legacy MAX_PATH limit (260 characters) succeeds because std converts paths to extended-length (\\?\) form internally, but keep() and persist() then fail with ERROR_PATH_NOT_FOUND (os error 3): they pass raw paths to SetFileAttributesW and MoveFileExW. This resolves the path against the current directory and converts it to extended-length form before those Win32 calls (UNC paths become \\?\UNC\...), falling back to the raw encoding if conversion fails.

Testing

Reproduced on Windows with a nested temp directory tree over 260 characters: creation succeeded while keep() and both persist() arms returned os error 3; all pass after the fix. Added test_windows_long_paths, which fails without the fix and passes with it. Full cargo test --workspace green; clippy and fmt clean.

Checklist

  • bug reproduced before fix
  • root cause identified
  • bug fixed
  • tests passed

Creating a NamedTempFile in a directory whose path exceeds the legacy
MAX_PATH limit works because std converts paths to extended-length form
internally, but keep() and persist() pass raw paths to SetFileAttributesW
and MoveFileExW, which then fail with ERROR_PATH_NOT_FOUND (os error 3).

Resolve the path against the current directory and convert it to the
extended-length \\?\ form (UNC paths to \\?\UNC\server\share) before
calling into Win32, falling back to the plain encoding if the conversion
fails.

Fixes Stebalien#444
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant