FileSystem.roots behavior is incomplete on win32

Could you suggest a patch for this that we could review?

Why not? Would I have the time this week, I'll make your patch.

Ok larsivi. I've made the patch. But you've got to read through the following treatise while reviewing.

Backward compability.

Volume management functions are somewhat new to Windows platforms, starting I guess from Win2k. To make the code executable on platforms before Win2k I use on-demand function loading in my code. For example, roots() on Win2k will return drive letters as well as volume mount points, while on Win9x/Me/NT it will just return the letters, still working fine for the same compiled program (well, theoretically). It is to be turned on by version=StaticLinkage?.

I have provided a batch file with options to build win9x-compatible version (as well as other variants) and I have tested that this version works both on Win98 and WinXP. Though I have had to turn off backward-incompatible tango modules, like Stdout, and let dsss rebuild tango library code.

Applications.

I see that runtime symbol loading functionality can be useful for more tasks, such as working with file links, reparse points, ACLs, and probably with tasks not concerning the file system. So, maybe we should move this crap to SharedLib??

Anyway, weaving it all together is your task =)

Grouping.

I have also added rootsByVolume() function that returns the same root set, grouping roots belonging to the same logical volume. It makes sense e.g. if one is searching for a particular file and he doesn't want to scan one volume twice. It also makes sense in file moving operations: if a file belongs to the same volume, it can just be renamed instead of a real removal; though this requires taking symlinks into account.

I'm sure the same thing could be done in posix, maybe by examining fstab. And nope I ain't gonna help with this =)

Post scriptum.

I thought I should note that FileSystem?.roots() (posix version) contains some code relying on the evaluation order:

line 527: path ~= Integer.parse(content[++i..i+3], 8u);

D specs do not define the order of SliceExpression? evaluation so it is not portable. Am I wrong?

patch source

I believe we have dropped making extraneous efforts to support Win95/98, thus making Win2K the earliest we try to support. If dropping support for those versions simplifies the code, then I think we should do that.

You could also look at the IPv6 code which had similar issues.

As for Posix (Linux), at some point it returned stuff from fstab, but I think it maybe was removed as it wasn't particularly portable across Posix. Maybe there is a posix standard to get to this information though?

Replying to larsivi:

I believe we have dropped making extraneous efforts to support Win95/98, thus making Win2K the earliest we try to support. If dropping support for those versions simplifies the code, then I think we should do that.

Ok I'm in. No point in carrying out the dead. I guess should linux drop its support for three-decades-old-crutches it might even become usable.

But since I wrote this piece already compatible with 9x let it remain as such.

You could also look at the IPv6 code which had similar issues.

What issues? of compability? or of the result incompleteness?

As for Posix (Linux), at some point it returned stuff from fstab, but I think it maybe was removed as it wasn't particularly portable across Posix. Maybe there is a posix standard to get to this information though?

Don't have a clue. Let some linux gurus think this out.