Some time ago, the .net developers finally saw sense and removed path normalization and long path limit code in System.IO: https://blogs.msdn.microsoft.com/jeremykuhne/2016/06/21/more-on-new-net-path-handling/
Some time ago, the .net developers finally saw sense and removed path normalization and long path limit code in System.IO: https://blogs.msdn.microsoft.com/jeremykuhne/2016/06/21/more-on-new-net-path-handling/
Does anybody know if Embarcadero have come to their senses and done the same in their System.IOUtils knock off? I no longer have an up to date subscription so cannot check this.
https://blogs.msdn.microsoft.com/jeremykuhne/2016/06/21/more-on-new-net-path-handling/
Does anybody know if Embarcadero have come to their senses and done the same in their System.IOUtils knock off? I no longer have an up to date subscription so cannot check this.
https://blogs.msdn.microsoft.com/jeremykuhne/2016/06/21/more-on-new-net-path-handling/
It’s not entirely Delphi’s fault. I don’t use non-windows OS-es with delphi, but I expect different behavior outside of windows.
ReplyDeleteJust watch out that when you skip normalization and ignore MAX_PATH while writing, that you run the risk that your stuff might not be usable from other software. Or well, even other parts of your own code.
The widestring versions of the winapi usually support the \\?\ prefix, but not all. (Crappy!)
Unless you stick to “compatible” paths, which would also defeat the purpose of skipping normalization and ignoring MAX_PATH in the first place. :-)
But yeah, for reading files it’s of course best to properly deal with Unicode paths with extra dots and spaces that are thousands of characters long.
I wonder how the dotnet guys solved this mess... did they find an elegant solution? Any recommended reads?