Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

long paths not supported on windows for rename, getFileStatus #56

Open
joeyh opened this issue Jul 12, 2022 · 1 comment
Open

long paths not supported on windows for rename, getFileStatus #56

joeyh opened this issue Jul 12, 2022 · 1 comment

Comments

@joeyh
Copy link
Contributor

joeyh commented Jul 12, 2022

System.PosixCompat.Files.rename will fail if a filename is longer than 285 characters or so, which is a default limit in Windows.

This is because it uses moveFileEx from Win32, and Win32 is a direct mapping to the win32 api. However, the problem could be avoided if the path were converted to "UNC-style" first. That conversion is how ghc is generally supporting long filenames on windows.

One easy fix would be to depend on directory-1.3.9.0 and use renamePath instead of moveFileEx. It so happens that renamePath does do UNC-style conversion, before passing it off to Win32.

(There are probably some other functions that also don't support long filenames.)

github-actions bot pushed a commit to datalad/git-annex that referenced this issue Jul 12, 2022
On Windows, that does not support long paths
jacobstanley/unix-compat#56

Instead, use System.Directory.renamePath, which does support long paths.

Sponsored-by: Dartmouth College's Datalad project
@joeyh
Copy link
Contributor Author

joeyh commented Mar 1, 2023

getFileStatus is another function from unix-compat that does not support long filenames. It's using createFile from Win32. Doing UNC-style conversion in getFileStatus would avoid this portability land-mine.

@joeyh joeyh changed the title long paths not supported on windows for rename long paths not supported on windows for rename, getFileStatus Mar 1, 2023
github-actions bot pushed a commit to datalad/git-annex that referenced this issue Mar 1, 2023
Works around this bug in unix-compat:
jacobstanley/unix-compat#56
getFileStatus and other FilePath using functions in unix-compat do not do
UNC conversion on Windows.

Made Utility.RawFilePath use convertToWindowsNativeNamespace to do the
necessary conversion on windows to support long filenames.

Audited all imports of System.PosixCompat.Files to make sure that no
functions that operate on FilePath were imported from it. Instead, use
the equvilants from Utility.RawFilePath. In particular the
re-export of that module in Common had to be removed, which led to lots
of other changes throughout the code.

The changes to Build.Configure, Build.DesktopFile, and Build.TestConfig
make Utility.Directory not be needed to build setup. And so let it use
Utility.RawFilePath, which depends on unix, which cannot be in
setup-depends.

Sponsored-by: Dartmouth College's Datalad project
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

No branches or pull requests

1 participant