Yeah seems silly for .net to have a limit like that.
I know that I have seen a few programs - one was a MSFT addon for VS that had issues with folder and filenames beeing to long.
very frustrating esp. when some of the problem came from folders with names that MSFT created!
today I would say that WIndows and .Net should drop the "MAX_PATH" limit and just warn that at some point a large name or path might not work.
but we should be able to have as many folders as we care to manage. to nest them as deep as we want. and to name files just about as long as we care to.
And I would drop the .xxx crap. in place have a 32 bit int that id's the "file type" in a table and put that int in the files meta-data.
so we do not need .docx to have the pc know that it's a word file.
On the Univac 1108 operating system (before you were born) there were things called program files that contain elements. Elements are symbolic, relocatable, absolute, and omnibus. Symbolic elements are simple text files. They have a maximum 12-character
element name and a maximum 12-character version name. Also included is a six-bit symbolic type so you can tell a Fortran program from a COBOL program. Your idea of a 32-bit property in metadata is thus proven to work. MSFT has been trying to hide the filename
extension by making it disappear from Windows Explorer unless you decide not to go with the default. Seems kinda lame to have a file type identifier be part of the name of the file. Worked in the Windows progenitor operating systems. But this is now 30