Paket exe can't handle paths that are longer than 260 characters.

Created on 31 Jul 2015 · 13Comments · Source: fsprojects/Paket

Between version 1.19.6 and 1.19.7 Paket became unable to handle paths longer than 260 characters. any paket operation, whether via command line or VS integration, blows up with a PathTooLongException now in a solution we have that is a web app, and so has very long nested node_modules directories.

Source

baronfel

Most helpful comment

Hi,

I still get the issue especially with the new core libs which have really long name like
runtime.opensuse.42.1-x64.runtime.native.System.Security.Cryptography.OpenSsl

bhugot on 17 Mar 2017

👍5

All 13 comments

Detailed stack trace:

Paket failed with: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. StackTrace: at System.IO.Path.NormalizePath(String path, Boolean fullCheck, Int32 maxPathLength, Boolean expandShortPaths) at System.IO.Path.GetDirectoryName(String path) at System.IO.FileSystemEnumerableIterator1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler1 resultHandler, Boolean checkHost) at System.IO.DirectoryInfo.InternalGetFiles(String searchPattern, SearchOption searchOption) at <StartupCode$Paket-Core>.$ProjectFile.search@55-2(String pattern, DirectoryInfo di) at Microsoft.FSharp.Collections.ArrayModule.Collect[T,TResult](FSharpFunc2 mapping, T[] array)
at .$ProjectFile.search@55-2(String pattern, DirectoryInfo di)
at Microsoft.FSharp.Collections.ArrayModule.CollectT,TResult
at .$ProjectFile.search@55-2(String pattern, DirectoryInfo di)
at Microsoft.FSharp.Collections.ArrayModule.CollectT,TResult
at .$ProjectFile.search@55-2(String pattern, DirectoryInfo di)
at Microsoft.FSharp.Collections.ArrayModule.CollectT,TResult
at .$ProjectFile.search@55-2(String pattern, DirectoryInfo di)
at Microsoft.FSharp.Collections.ArrayModule.CollectT,TResult
at .$ProjectFile.search@55-2(String pattern, DirectoryInfo di)
at Microsoft.FSharp.Collections.ArrayModule.CollectT,TResult
at .$ProjectFile.search@55-2(String pattern, DirectoryInfo di)
at Microsoft.FSharp.Collections.ArrayModule.CollectT,TResult
at .$ProjectFile.search@55-2(String pattern, DirectoryInfo di)
at Microsoft.FSharp.Collections.ArrayModule.CollectT,TResult
at .$ProjectFile.search@55-2(String pattern, DirectoryInfo di)
at Microsoft.FSharp.Collections.ArrayModule.CollectT,TResult
at .$ProjectFile.search@55-2(String pattern, DirectoryInfo di)
at Microsoft.FSharp.Collections.ArrayModule.CollectT,TResult
at .$PublicAPI.[email protected](Unit unitVar0)
at Paket.Utils.RunInLockedAccessModea
at Paket.Program.processWithValidationT
at Paket.Program.[email protected](Command command, String[] args)
at Paket.Program.main()`

baronfel on 31 Jul 2015

also reported in https://twitter.com/chrismckee/status/626756973283950592

forki on 31 Jul 2015

we could try adding support for the \\?\<FILEPATH> syntax, which opts-in to long path support in win32: http://blogs.msdn.com/b/bclteam/archive/2007/02/13/long-paths-in-net-part-1-of-3-kim-hamilton.aspx

baronfel on 31 Jul 2015

+1 When it does find all refs is it scanning all the folders? Just wondering as I have a 'master' folder in my repo which isnt part of the solution, in there is some frontend crap for gulp that handles live reload etc; It's only the npm folder in here that exceeds the win limit (mostly caused by lodash dependencies). But I wouldn't expect Paket to be looking at anything thats not in SLN/CSProj

ChrisMcKee on 31 Jul 2015

could you please check if 1.22.0-alpha005 fixes it?
you can use paket.bootstrapper.exe prerelease to get that version

forki on 31 Jul 2015

it does fix the issue for me. Thanks for the quick turnaround, @forki.

baronfel on 31 Jul 2015

ok cool. will release a proper version.

forki on 31 Jul 2015

done http://fsprojects.github.io/Paket/release-notes.html

forki on 31 Jul 2015

Yup that wins :) Thanks

ChrisMcKee on 31 Jul 2015

can you also push an update of Paket.VisualStudio to contain this fix? It's a bit of heartburn for us without it.

baronfel on 31 Jul 2015

Already done
On Jul 31, 2015 20:32, "Chester Husk III" [email protected] wrote:

can you also push an update of Paket.VisualStudio to contain this fix?
It's a bit of heartburn for us without it.

—
Reply to this email directly or view it on GitHub
https://github.com/fsprojects/Paket/issues/949#issuecomment-126777919.

forki on 31 Jul 2015

Hi,

I still get the issue especially with the new core libs which have really long name like
runtime.opensuse.42.1-x64.runtime.native.System.Security.Cryptography.OpenSsl

bhugot on 17 Mar 2017

👍5

The PathTooLong Exception is still happening
Paket failed with: -> PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

What broke it again?