-
Notifications
You must be signed in to change notification settings - Fork 27
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
Comments
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
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
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
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.)
The text was updated successfully, but these errors were encountered: