On 09/22/2018 04:46 PM, Jonathan Marler wrote:
Decided to play around with this for a bit. Made a "proof of concept"
library:
https://github.com/marler8997/longfiles
It's just a prototype/exploration on the topic. It allows you to
include "stdx.longfiles" instead of "std.file" which will enable the
conversion in every call, or you can import "stdx.longfiles :
toLongPath" and use that on filenames passed to std.file.
Cool! Will have to take a closer look and try it out.
Regarding this: "TODO: what should be done about the MS-DOS FAT
filesystem?"...
First of all, FAT16 can still be fully-used with the current interfaces
anyway - it's just that if you attempt anything FAT16 doesn't support,
the error you get will come from the OS rather than a D lib. But
*unlike* the non-`\\?\` path issues, there really isn't anything here
that needs to be worked around, or that even *can* be sensibly worked
around.
Besides, FAT16 is a rarely-used, long-since-outdated legacy format. Its
successor, FAT32 has been around for more than 20 years, and I'm not
aware of anything more recent than the 3.5" floppy that uses it by
default. I'd say it safely falls into the category of "Too much of an
esoteric special-case to be worth requiring that special support be
added in the main 'path of least resistance' interface (as long as
there's nothing preventing the user from handling it on their own if
they really need to.)"
