4 ms·

Funnily enough, not just the fact that users and developers need to care about drive letters, the drive C: itself is called drive C: because drives A: and B: we

by yason 11y ago

Funnily enough, not just the fact that users and developers need to care about drive letters, the drive C: itself is called drive C: because drives A: and B: were reserved for floppy drives. And I don't think many machines have had floppy drives in the 2000's. Linux has had a unified directory tree since the early 90's where it completely doesn't matter which drives host which directories. Implementing such a tree on Windows and mapping "C:", "D:" etc. as pseudo-roots to suitable locations to make it backwards compatible would not be an insurmountable task. Surely not trivial, but even on Windows application programs do not write to physical drives directly which gives the filesystem an opportunity to do any path translations it wants to. Thus, the question becomes a matter of will: Why hasn't Microsoft considered it important to fix their drive accesses? What do they see as the advantage of having drives mapped to drive letters? It's certainly not usability: Linux can produce "drive icons" for each mounted drive. You plug in a USB stick and its icon shows up on the desktop――all this regardless of whether the USB stick is actually mounted in /mnt/$STICK or /media/$USER/$STICK or wherever. They could also support mounting extra drives to directories under C: so that the user would never have to deal with other drive letters. The "C:" would just be a historical prefix but in practice it wouldn't matter because you could mount your second disk at C:\Program Files\ and the applications wouldn't even know about it. I vaguely remember that WinNT kernel could actually do this, however it's apparently well-hidden from users because I don't see this having been set up anywhere.

charonn0 11y ago
You can mount a volume, even one that is already mounted with a drive letter, under any empty NTFS directory. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365733(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...
- josteink 11y ago
  While this is true, most Windows software is not prepared to treat this as a volume. And you still need the root to be a drive-letter in itself.
  - charonn0 11y ago
    Most Windows applications don't know, since it's handled transparently by the filesystem driver, and a mounted volume need not have a drive letter at all.
cyphax 11y ago
> They could also support mounting extra drives to directories under C: so that the user would never have to deal with other drive letters. The "C:" would just be a historical prefix but in practice it wouldn't matter because you could mount your second disk at C:\Program Files\ and the applications wouldn't even know about it. I vaguely remember that WinNT kernel could actually do this, however it's apparently well-hidden from users because I don't see this having been set up anywhere. Windows can indeed do this (since Windows 2000). It's not necessarily hidden, but the OS defaults to using drive letters for (new) partitions and most people don't mind. In Disk Management you can assign not only drive letters but also mount points for a partition (or both). I suppose you are left with the C-drive to be more or less / like you mentioned. I don't know if programs run into trouble because of hard coding of paths but that wouldn't be so much Microsoft's fault I think. I used to mount a USB-stick this way because it only contained a Truecrypt container, which would get its own drive letter thru Truecrypt so I didn't care to have two drive letters for one piece of storage. :) https://en.wikipedia.org/wiki/NTFS_volume_mount_point https://en.wikipedia.org/wiki/NTFS_volume_mount_point
- Rafert 11y ago
  As usual the problem is with badly behaving software. E.g. I have a bunch of software storing its crap in C:\Users\JohnDoe\Documents\ while I've changed the location of that folder to D:\JohnDoe\Documents.
  - freeone3000 11y ago
    That's what happens when a folder accesses the actual path when you've changed the CSIDL ID (relocating documents). If you've done it as an NTFS reparse point, there wouldn't be any such C:\Users\JohnDoe\Documents, and trying to navigate there would put you in D:\.
ekianjo 11y ago
> would not be an insurmountable task WINE already does it just fine.
ygra 11y ago
Windows has, at the kernel level, a single hierarchy of all devices and filesystems. I'd still say the main reason for having drive letters in userspace is backwards compatibility. Remember how DOS allowed drive letters in front of UNC paths to trick path validation routines? Same thing here. Heck, cmd.exe even continues to support different current directories on different drives [π] (use set " to see the hidden environment variables [−1]) because presumably a bunch of batch files relied on that. And yes, you can trivially mount volumes in folders [⅜] (at least since Windows 2000, if not for longer). I did this for quite a while, although currently I've gone the other way and use drive letters as short forms for some folders I regularly use (H: is my home directory, for example, also mapped to Home: in PowerShell). So to shorten all this: From a user perspective there is little difference. A normal Windows user certainly wouldn't care about whether his documents are in C:\Users\Foo\Documents or in \Users\Foo\Documents. For many people nowadays there is only one volume anyway, so C: is just a prefix to the only filesystem hierarchy people care about. From a kernel standpoint things don't need to change either, because there is only a single hierarchy at that level. Which leaves applications running on Windows, where I'd also not see a particularly compelling benefit except for the rare case to iterate all files on all drives which is a two-step process instead of starting at the hierarchy root. So marginal benefit on one side, and the potential to break thousands, if not millions of existing applications, scripts, etc., of which many are probably in use but not supported or updated anymore. I'd encourage you to read Raymond Chen's blog some day. For an ecosystem as old as Windows (which does not rely on published source code of applications, which could be patched indefinitely to make it run on incompatible newer versions) backwards compatibility is a major reason why it's still used and relevant. And at that point you learn to live with minor historic design issues (MAX_PATH is another; on the other side of the fence, just look how long and painful the way away from X is). ___________ [π] https://blogs.msdn.microsoft.com/oldnewthing/20101011-00/?p=12563 https://blogs.msdn.microsoft.com/oldnewthing/20101011-00/?p=... [−1] https://blogs.msdn.microsoft.com/oldnewthing/20100506-00/?p=14133/ https://blogs.msdn.microsoft.com/oldnewthing/20100506-00/?p=... [⅜] http://www.howtogeek.com/wp-content/uploads/2014/05/clip_image017.png http://www.howtogeek.com/wp-content/uploads/2014/05/clip_ima...
revelation 11y ago
You missed out the part "why would they do any of this". You can't just list the things Linux manages to do regardless of their unified tree, you got to explain the benefits. I think it's a perfectly fine distinction to make, and having devices always mount at the root seems a very reasonable restriction that actually helps novice users. One could of course also argue that the unified tree is merely an artifact of having to store all kinds of OS information as files in that same tree, when they are not really actual files...
stordoff 11y ago
What are the user advantages to a unified directory tree? I've always found drive letters to be a moderately useful abstraction (I've been tripped up a few times on my Linux server when moving 20GB+ video files around - if I forget /home and /srv are mounted on different drives, a move operation takes a long time, but having separate drive letters makes it more immediately obvious).
daurnimator 11y ago
windows does have a root hierarchy. "C:" is just shortcut for "\DosDevices\C:" which is just an alias to "\Device\ActualDeviceName". See https://msdn.microsoft.com/en-us/library/windows/hardware/ff548088(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/hardware/ff...

by yason 11y ago

charonn0 11y ago

You can mount a volume, even one that is already mounted with a drive letter, under any empty NTFS directory. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365733(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

josteink 11y ago
While this is true, most Windows software is not prepared to treat this as a volume. And you still need the root to be a drive-letter in itself.
- charonn0 11y ago
  Most Windows applications don't know, since it's handled transparently by the filesystem driver, and a mounted volume need not have a drive letter at all.

cyphax 11y ago

> They could also support mounting extra drives to directories under C: so that the user would never have to deal with other drive letters. The "C:" would just be a historical prefix but in practice it wouldn't matter because you could mount your second disk at C:\Program Files\ and the applications wouldn't even know about it. I vaguely remember that WinNT kernel could actually do this, however it's apparently well-hidden from users because I don't see this having been set up anywhere. Windows can indeed do this (since Windows 2000). It's not necessarily hidden, but the OS defaults to using drive letters for (new) partitions and most people don't mind. In Disk Management you can assign not only drive letters but also mount points for a partition (or both). I suppose you are left with the C-drive to be more or less / like you mentioned. I don't know if programs run into trouble because of hard coding of paths but that wouldn't be so much Microsoft's fault I think. I used to mount a USB-stick this way because it only contained a Truecrypt container, which would get its own drive letter thru Truecrypt so I didn't care to have two drive letters for one piece of storage. :) https://en.wikipedia.org/wiki/NTFS_volume_mount_point https://en.wikipedia.org/wiki/NTFS_volume_mount_point

Rafert 11y ago
As usual the problem is with badly behaving software. E.g. I have a bunch of software storing its crap in C:\Users\JohnDoe\Documents\ while I've changed the location of that folder to D:\JohnDoe\Documents.
- freeone3000 11y ago
  That's what happens when a folder accesses the actual path when you've changed the CSIDL ID (relocating documents). If you've done it as an NTFS reparse point, there wouldn't be any such C:\Users\JohnDoe\Documents, and trying to navigate there would put you in D:\.

ekianjo 11y ago

> would not be an insurmountable task WINE already does it just fine.

ygra 11y ago

Windows has, at the kernel level, a single hierarchy of all devices and filesystems. I'd still say the main reason for having drive letters in userspace is backwards compatibility. Remember how DOS allowed drive letters in front of UNC paths to trick path validation routines? Same thing here. Heck, cmd.exe even continues to support different current directories on different drives [π] (use set " to see the hidden environment variables [−1]) because presumably a bunch of batch files relied on that. And yes, you can trivially mount volumes in folders [⅜] (at least since Windows 2000, if not for longer). I did this for quite a while, although currently I've gone the other way and use drive letters as short forms for some folders I regularly use (H: is my home directory, for example, also mapped to Home: in PowerShell). So to shorten all this: From a user perspective there is little difference. A normal Windows user certainly wouldn't care about whether his documents are in C:\Users\Foo\Documents or in \Users\Foo\Documents. For many people nowadays there is only one volume anyway, so C: is just a prefix to the only filesystem hierarchy people care about. From a kernel standpoint things don't need to change either, because there is only a single hierarchy at that level. Which leaves applications running on Windows, where I'd also not see a particularly compelling benefit except for the rare case to iterate all files on all drives which is a two-step process instead of starting at the hierarchy root. So marginal benefit on one side, and the potential to break thousands, if not millions of existing applications, scripts, etc., of which many are probably in use but not supported or updated anymore. I'd encourage you to read Raymond Chen's blog some day. For an ecosystem as old as Windows (which does not rely on published source code of applications, which could be patched indefinitely to make it run on incompatible newer versions) backwards compatibility is a major reason why it's still used and relevant. And at that point you learn to live with minor historic design issues (MAX_PATH is another; on the other side of the fence, just look how long and painful the way away from X is). ___________ [π] https://blogs.msdn.microsoft.com/oldnewthing/20101011-00/?p=12563 https://blogs.msdn.microsoft.com/oldnewthing/20101011-00/?p=... [−1] https://blogs.msdn.microsoft.com/oldnewthing/20100506-00/?p=14133/ https://blogs.msdn.microsoft.com/oldnewthing/20100506-00/?p=... [⅜] http://www.howtogeek.com/wp-content/uploads/2014/05/clip_image017.png http://www.howtogeek.com/wp-content/uploads/2014/05/clip_ima...

revelation 11y ago

You missed out the part "why would they do any of this". You can't just list the things Linux manages to do regardless of their unified tree, you got to explain the benefits. I think it's a perfectly fine distinction to make, and having devices always mount at the root seems a very reasonable restriction that actually helps novice users. One could of course also argue that the unified tree is merely an artifact of having to store all kinds of OS information as files in that same tree, when they are not really actual files...

stordoff 11y ago

What are the user advantages to a unified directory tree? I've always found drive letters to be a moderately useful abstraction (I've been tripped up a few times on my Linux server when moving 20GB+ video files around - if I forget /home and /srv are mounted on different drives, a move operation takes a long time, but having separate drive letters makes it more immediately obvious).

daurnimator 11y ago

windows does have a root hierarchy. "C:" is just shortcut for "\DosDevices\C:" which is just an alias to "\Device\ActualDeviceName". See https://msdn.microsoft.com/en-us/library/windows/hardware/ff548088(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/hardware/ff...