Long Paths in Windows 10

IMHO longer paths than 260 characters have never been a limitation of NTFS but of windows and the windows api.

Since some months Windows 10 seems to be able to handle longer paths under special circumstances according to these articles:

http://winaero.com/blog/how-to-enable-ntfs...-in-windows-10/
http://www.tenforums.com/tutorials/51704-n...ndows-10-a.html
http://www.howtogeek.com/266621/how-to-mak...260-characters/

I habe no real software-engeneering knowledge but if it is indeed possible to change mp3tag with this mentioned manifest-file i would very much appreciate if mp3tag would be updated to handle extra long paths.

  • as far as I know many M$ SDK / API Calls can not handle path > 260 chars
  • this is still not an official solution/supported way
  • mp3tag use external lib's that maybe also can not handle that

Hi
the limit comes from the API that MP3tag uses since Windows 2000 (NTFS could since NT3.1 use 32k characters (absolute path+filename together). As soon as Florian (made a suggestion about a year ago as most filenames are much longer than 600characters due to my naming convention, which I have to cut infront of using Mp3tag, and reedit them later ) would use the ntfs namespace lib via
\\?\GLOBALROOT or \\.\ it would be solved.
As I have offered money to implement it (which was not answered), there's still the problem with most apps that don't handle the path NOR the filename at more than 252 (or so) character (absolute path+filename together). So a lot of users would cry out when there external players don't work out of mp3tag anymore or produce errors.

I'd like to have it since that moment I switched from ape tag editor (commandline) to MP3tag and discovered the limitation (before I used ZFS under Linux which handles long path+filenames very good since it's start)

Cheers
Sam

This was my starting question about LFN in May 2015:
/t/16896/1

some older "workarounds" are from 2010. As mentioned it's pretty easy to implement via the Namespaces