5 ms·

In the release notes it says the MAXPATH file name limitation is fixed. Does that mean what I think, and we're now free to have things deeply nested with arbit

In the release notes it says the MAXPATH file name limitation is fixed. Does that mean what I think, and we're now free to have things deeply nested with arbitrarily long names? ~32768 characters according to the docs. I frequently hit this problem, especially with a git repository inside of a solution with a huge name. This is great and I wonder if this will incentivize vendors to finally recompile some of their old applications or if the *.config file change will be good enough.

MichaelGG 10y ago
This is just for the .NET wrappers. Other code might still have issues. Doesn't seem like recompiling is needed; as you mention there's a config switch. (You wouldn't have to recompile anyways; the targeting is just some metadata, so you could just change the already-compiled code unless they do their own binary verification.)
dogma1138 10y ago
Yes it was originally the same as the UNC path limit which was 260 chars. Microsoft (a while ago) has updated WinAPI to support unicode and under extended-length paths has lifted the limit up to 32,767 chars it seems that now .NET matched this also. https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx https://msdn.microsoft.com/en-us/library/aa365247(VS.85).asp...
- poizan42 10y ago
  "A while ago"? That was at least back in NT 3.5
  - dogma1138 10y ago
    IIRC the MAX_PATH limit was lifted from Win32 with one of the Windows 10 builds. But it's true that unicode support was there for a "while" ;) the limit however was still enforced, so I should've been more clear that only the restriction lifting was more recent than 2 decades past.
julianz 10y ago
Interview with the person removing filename limitations here, it's an interesting discussion about a horrible, hard problem. https://www.dotnetrocks.com/?show=1320 https://www.dotnetrocks.com/?show=1320
tracker1 10y ago
One niggle, you still may have issues with Windows explorer, so if it's a path you need to navigate to, be careful... That said, I still don't get why .Net 1.0 didn't do this, I also don't get why they haven't fixed Windows explorer's long file/directory name support.
- tracker1 10y ago
  Looks like the Windows 10 update recently corrected a lot of the Path issues, so will have to see if this works now...
Amiga64 10y ago
I don't see why people obsess about the MAXPATH as it's quite possible to get 32,768 characters, just use UNC paths with .NET which has been supported since I don't know when; you just need some DLL imports. https://ingehenriksen.wordpress.com/2015/05/23/how-to-work-with-file-paths-longer-than-260-characters-in-net/ https://ingehenriksen.wordpress.com/2015/05/23/how-to-work-w...
- WorldMaker 10y ago
  This does the DLL imports for you now and supports it across the board for everything that for everything that uses System.IO, which means once your app opts in you can use just about anything in the .NET ecosystem you want and trust it will work (say, a .NET 2 logging library that your company mandates). (It still needs UNC-like paths in some cases, but that's Windows back compat for you.)

MichaelGG 10y ago

This is just for the .NET wrappers. Other code might still have issues. Doesn't seem like recompiling is needed; as you mention there's a config switch. (You wouldn't have to recompile anyways; the targeting is just some metadata, so you could just change the already-compiled code unless they do their own binary verification.)

dogma1138 10y ago

Yes it was originally the same as the UNC path limit which was 260 chars. Microsoft (a while ago) has updated WinAPI to support unicode and under extended-length paths has lifted the limit up to 32,767 chars it seems that now .NET matched this also. https://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx https://msdn.microsoft.com/en-us/library/aa365247(VS.85).asp...

poizan42 10y ago
"A while ago"? That was at least back in NT 3.5
- dogma1138 10y ago
  IIRC the MAX_PATH limit was lifted from Win32 with one of the Windows 10 builds. But it's true that unicode support was there for a "while" ;) the limit however was still enforced, so I should've been more clear that only the restriction lifting was more recent than 2 decades past.

julianz 10y ago

Interview with the person removing filename limitations here, it's an interesting discussion about a horrible, hard problem. https://www.dotnetrocks.com/?show=1320 https://www.dotnetrocks.com/?show=1320

tracker1 10y ago

One niggle, you still may have issues with Windows explorer, so if it's a path you need to navigate to, be careful... That said, I still don't get why .Net 1.0 didn't do this, I also don't get why they haven't fixed Windows explorer's long file/directory name support.

tracker1 10y ago
Looks like the Windows 10 update recently corrected a lot of the Path issues, so will have to see if this works now...

Amiga64 10y ago

I don't see why people obsess about the MAXPATH as it's quite possible to get 32,768 characters, just use UNC paths with .NET which has been supported since I don't know when; you just need some DLL imports. https://ingehenriksen.wordpress.com/2015/05/23/how-to-work-with-file-paths-longer-than-260-characters-in-net/ https://ingehenriksen.wordpress.com/2015/05/23/how-to-work-w...

WorldMaker 10y ago
This does the DLL imports for you now and supports it across the board for everything that for everything that uses System.IO, which means once your app opts in you can use just about anything in the .NET ecosystem you want and trust it will work (say, a .NET 2 logging library that your company mandates). (It still needs UNC-like paths in some cases, but that's Windows back compat for you.)