Drives and Namespaces

[cppm]

In the developer FAQ:

I have an idea: Why not throw away these odd drive letters?

This is an old idea. Microsoft has probably had this idea, but they have not implemented it yet. In the ReactOS team there are also thoughts about this issue. But up to now there has not been a sufficient conclusion on this topic. There are ideas such as having a memory based mount file system or uncovering the object manager's name space to win32 apps or drive words, but each approach has disadvantages. Note: The ReactOS/Microsoft(R) Windows(R) NT Kernel doesn't work with drive letters. These are a relic of DOS (or should I say CP/M) in Win32.

Right, everything that the FAQ says is perfectly correct, but i don't feel we should be so hasty to just emulate the windows way of dealing with files.

so...

We are aware that the drive letters are mappings of NT device URI's

eg: \\.\PhysicalDrive0\Partition3 --> C:\

Right? We are also aware that drives can be assigned to other things, such as SMB shares:

\\MSHOME\COMPA\Music ---> M:\

And even locations on other dosdevices:

C:\Users\Bob\ ---> P:\

We are also aware that with a simple IFS we can have a new backend for the filesystems behind the drive letters, and that locations on drive letters can be linked to one another, and you can have several drive letters pointing to the same physical device, and other interesting permutations.

Essentially there is supposed to be a pretty flexible system for mapping these drives, I imagine it's implemented somewhere in win32k, at a guess. In any case, what we have here is a way of mapping data sources, onto specificied labels ie "Drive Letters", which is relatively free of constraint, except that the label has to be a single letter or number (yes you can asssign 1-9 as drive letters) with no distinction between capitals and lowercase.

But seen objectively the drive mapping is a wonderful system that has simply been put to a distasteful use in maintaining backwards compatibility, which is the source of the alphanumeric constraint.

However, what if we were, 'expand the toolkit' so to speak and do away with the constraint, giving us instead of just plain dosdevices, but cool namespaces This way one could have situations such as.

\\.\PhysicalDrive0\Partition3\ ---> Root:\
\\MSHOME\COMPA\Music\ ---> Music:\
Root:\Users\Bob ---> Profile:\

And now that we are free from the 33 meaningless labels limit, even more creative things such as:

Registry:\, Drivers:\, BobsSQLDataBase:\, GMailAccount:\

To give an example of an interesting use of this system, one could use it to create a posix enviroment that posix apps can 'live in' so to speak.

Called Posix:\... (note folder delimiters (/,\) don't actually matter as long as the right one is delivered to the right applications, that's why NT has subsystems)

This could be made up of the following VFS:

/
/bin -> Root:\Reactos\bin
/home -> Root:\Users
/lib -> Root:\Reactos\System32
/tmp -> Root:\Reactos\Temp

(and interesting one's)

/dev -> Devices:\
/media -> Media:\

Having a system like this makes more sense than having some internal arbitrary namespace, as then it can be made accessible to other aspects of the running OS, as we see in the example for having /dev -> Devices:\

This is all well and good, and turns a cludgey feature into something more neat and suited for running subsystems side by side, and if we lived in a world where backwards compatibility wasn't an issue i'm sure it would be fine, however...

The obvious problem

The damacles sword over our head - Win32 Compatibility - means that we can't suddenly start giving Win32 applications drive labels which consist of more than one alphanumeric character, and expect them all to work. Granted many probably will handle it fine, never once actually inspecting the filenames they are passed, but for those that actually parse the path they could receive a nasty shock.

Since there's no real way of telling which applications those are the only real answer to this is to think of the labels as a neat idea but to protect win32 applications from them, just like we would protect POSIX applications from the drive letters...

We would then map these labels onto drive letters, with the alphanumeric constraint, however, i hear you say this is getting, we are back to the same old problem and nothing much has changed.

Except that drive letters are now a real and logical part of a modern operating system, that could be adapted and utilised if ever one was to use the NT basis for anything other than running win32 applications. Instead of an old and neccesary evil of an antiquitated file access system.

It also makes sense if you take some liberty with the win32 api, by sending a particular message a win32 application could signify that it is ready for extended drive labelling/namespaces and reveal the actual namespaces. If reactos were to ever be popular that would become a real possibility, especially among Open Source software.

Who, knows, I think it's a cool idea... what do you guys think?[/url]

[InFeRnODeMoN]

I really like shouting around "ZOMG! deed will break compatibility! n00b!", but this has a 100% success rate of breaking major stuff.

[cppm]

I really like shouting around "ZOMG! deed will break compatibility! n00b!", but this has a 100% success rate of breaking major stuff.

Yes, as long as it's done in an incorrect way.

Windows emerged from the dos paradigm by taking old things and redesigning them in ways that would expand them without breaking backwards compatibility, along with the NTVDM drive letters are the legacy of this, and MS is dropping the NTVDM in 64 bit versions of windows.

[Harteex]

I actually like drive letters. Easy to see where you have free diskspace etc instead of having different harddisks in different folders.

If you were to move to a unix style filesystem, at least skip those stupid three letter guess-what-I-do folders...

[oiaohm]

Sorry to say a lot of old program fail. Windows forbids giving drives multi letters. So drive letter drop down boxes are normally one char wide.

Freedos you could do that now. It does not care.

Now this is do able to a point. Most modern day programs use the file selector dialog and would not be broken by what he suggested.

Also there is a problem with making it longer. transport types. Like http: ftp: people could create folders like them. Just the \ the wrong and they go local. Or will be auto corrected and will not be accessible.

I would not rule it straight out lot of questions need answering. Are they any modern day applications effected by it and so on. There is a chance you could detect what applications will have problems by there api calls or pe version tag.

Having zzzzzz: drive in freedos is funny.

[shevegen]

One thing I like about the letters (in theory) is that, different to Unix / you can have "multiple" roots, or? Wheres in Unix a rm -rf / would remove everything, including mounted devices.

[cppm]

people who have replied saying that they 'actually quite like drive letters' because they enable multiple roots, miss the point, by expanding drive letters to drive labels, enables more meaningful roots, as well as having more than 36 of them, but still retaining the drive principle, nowhere did i suggest forcing a unix vfs upon win32 which would be systematically flawed.

In response to points made on the incompatibility of the idea (thank you Oiaohm) i think it impractical in general to make win32 use namespaces/drive labels. With further pondering upon it, i thought of a system where a 'mount' so to speak is given a meaningful name (like under unix with /media/whateveryouwanttocallme) but also given a win32 drive letter for compatibility.

It occurred to me then that windows actually already does this with drive labels, and arguably does it better than Ubuntu, since a partition's disk label is actually updated.

However I think further improvements can be made upon this model:

• abstracting the drive mapping functionality so that it can be used in a subsystem without win32, effectively creating a File System interface capable of multiple roots for any subsystem, and sharable between subsystems. (this might already be the case).

• Something kinda like FUSE for windows, if it's compatible with existing FUSE systems, with minimal code change, that'll be a big plus. If this is also usable outside of win32 that's even better. (I've heard some independent people are working on this)

• Further opening up of the rules for drives, so for example for me, any partition with the label "Core" I would always want assigned to the drive letter " P:".

• Generally making it possible for drives to be more consistent, so that moving to a system with an extra CD drive doesn't screw up your drive system

• An ability to use labeled drives, such as "Core:", if you know what you're doing, this might be used in embedded or server applications where the applications used are known and tested, and having a large number of meaningful drive mappings might come in handy (for datacenters anyway) as well as wierd people like me who'd try to see if they can get their desktop to behave that way .

This would be ideal, according to me, although i recognise that it's unlikely that any devs will see these rather incongruous details as worth time when simply getting a working kernel is a priority. Just if i knew NT well enough and was a much better programmer, I would be looking at this. Thanks anyway!