5 ms·

Right. Who wants to use a platform where you can't base64 the file's data into the filename?

by labster 11y ago

teddyh 11y ago
Not the base file name, the entire path to the file must be 255 characters or less.
- labster 11y ago
  Really? That sounds like a huge PITA. And here I've been complaining about HFS+ all this time, but the OS X APIs are better than that.
- wolfgke 11y ago
  Not true: They must be less than 2^15 characters long. If you use the standard file APIs on Windows (most applications do) there exists a limit of 260 characters for the path. To access longer paths you have to use the Shell API (only few applications do): > http://stackoverflow.com/a/31142839/497193 http://stackoverflow.com/a/31142839/497193
  - ygra 11y ago
    Uhm, Shell APIs are necessary when you're dealing with shell objects, but all filesystem APIs can work with paths longer than MAX_PATH iff you use the Unicode API (e.g. CreateFileW) and prefix the path with \\?\ [½]. They can't retroactively change MAX_PATH because it's a constant that's compiled in every application that uses it. Well-written applications these days will just do the \\?\ thing and be done with it. The downside of that is that you can get paths Explorer doesn't like. And I'm guessing Explorer explicitly doesn't allow you to create paths longer than MAX_PATH to prevent people complaining about »I created a folder in Explorer and copied a file there, but now I cannot open it.«. Keep in mind that (usually) developers can be expected to find solutions, but making it easy to frustrate regular users (of which the OS has at least a few hundred million) is not the best strategy to keep them using the OS. Of course, there are also heaps of software that cannot use above method to allow for longer paths because they don't use the Unicode APIs. Maybe because some developers think supporting Windows 98 is a good idea nowadays, or because they just don't know any better. And in that heap there's a lot of poorly-ported open-source software, too. [½] https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
Jtsummers 11y ago
The problem is deeply nested directory structures and sanely named directories. I got around this limitation at one job by mapping a drive deep into the directory structure, but it meant people going to the root on the network file server couldn't access the content I could (I used this work around because someone else had already done it and was cleaning it up). The directory structure made some sense, that is, it was sane and rational. But it should've been split across several network drives to keep things shallower given the limitation.

Right. Who wants to use a platform where you can't base64 the file's data into the filename?

by labster 11y ago

Right. Who wants to use a platform where you can't base64 the file's data into the filename?

teddyh 11y ago

Not the base file name, the entire path to the file must be 255 characters or less.

labster 11y ago
Really? That sounds like a huge PITA. And here I've been complaining about HFS+ all this time, but the OS X APIs are better than that.
wolfgke 11y ago
Not true: They must be less than 2^15 characters long. If you use the standard file APIs on Windows (most applications do) there exists a limit of 260 characters for the path. To access longer paths you have to use the Shell API (only few applications do): > http://stackoverflow.com/a/31142839/497193 http://stackoverflow.com/a/31142839/497193
- ygra 11y ago
  Uhm, Shell APIs are necessary when you're dealing with shell objects, but all filesystem APIs can work with paths longer than MAX_PATH iff you use the Unicode API (e.g. CreateFileW) and prefix the path with \\?\ [½]. They can't retroactively change MAX_PATH because it's a constant that's compiled in every application that uses it. Well-written applications these days will just do the \\?\ thing and be done with it. The downside of that is that you can get paths Explorer doesn't like. And I'm guessing Explorer explicitly doesn't allow you to create paths longer than MAX_PATH to prevent people complaining about »I created a folder in Explorer and copied a file there, but now I cannot open it.«. Keep in mind that (usually) developers can be expected to find solutions, but making it easy to frustrate regular users (of which the OS has at least a few hundred million) is not the best strategy to keep them using the OS. Of course, there are also heaps of software that cannot use above method to allow for longer paths because they don't use the Unicode APIs. Maybe because some developers think supporting Windows 98 is a good idea nowadays, or because they just don't know any better. And in that heap there's a lot of poorly-ported open-source software, too. [½] https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx#maxpath https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

Jtsummers 11y ago

The problem is deeply nested directory structures and sanely named directories. I got around this limitation at one job by mapping a drive deep into the directory structure, but it meant people going to the root on the network file server couldn't access the content I could (I used this work around because someone else had already done it and was cleaning it up). The directory structure made some sense, that is, it was sane and rational. But it should've been split across several network drives to keep things shallower given the limitation.