In this way, NT is similar to Unix in that many things are just files part of one global VFS layout (the object manager name space).
Paths that start with drive letters are called a "DOSPath" because they only exist for DOS compatibility. But unfortunately, even in kernel mode, different sub systems might still refer to a DOSPath.
Powershell also exposes various things as "drives", pretty sure you could create your own custom drive as well for your custom app. For example, by default there is the 'hklm:\' drive path:
I _suspect_ they mean that certs imported into MMC in Windows can be accessed at magic paths, but...yeah linux can do that because it skips the step of making a magical holding area for certs.
Don't have to use PowerShell either, it's been available for ages through Disk Management. Right-click on a partition -> Change Drive Letter and Path -> Add -> Mount in following empty NCTS folder.
Only for NTFS (both source and dest) though, no exFAT shared drives under a folder mount or what have you. I think the same is actually true of ReFS for some reason.
When you create/format the partition in the GUI tools it'll actually ask if you want to assign a drive letter or mount as a path as well.
NTFS mount points can be very handy for engineering around software that doesn't allow you to customize paths. I can choose VM disks with different performance or replication policies and stitch them together like I would on a *nix OS. It's very handy and only in rare occasions have I had applications "notice" it and balk.
Yeah only the DOS façade of Windows NT is well known. Under that skin lurks some pretty wild late-1980s concepts. One of the core things to understand is that a lot of the features are based on a reverse map of GUIDs to various actions, and resolution of these map entries pervades the UI. That's why you can put {hexspew} as the name of a shortcut on the Windows desktop and have it magically become a deep link to some feature that Windows doesn't otherwise let you create a shortcut to, and also why you can just add things to the control panel which doesn't seem like it would be an intentional feature. And these actions can be named symbols inside DLLs, so they can do literally anything the OS is capable of doing. This is also why Windows has always been ground zero for malware.
>so they can do literally anything the OS is capable of doing
Yea, over the years someone thought of something they wanted to do and then did it without a systematic consideration of what that level of power meant, especially as multi-user network connectivity and untrusted data became the norm.
You would be limited to a fairly small subset of emojis, anyway: many (most?) of them are outside of the BMP so don’t fit into a single UTF-16 code unit, and some of the remaining ones are ordinary characters followed by an emoji style selector (U+FE0F), which doesn’t fit either.
> Drives with a drive-letter other than A-Z do not appear in File Explorer, and cannot be navigated to in File Explorer.
Reminds me of the old-school ALT + 255 trick on Win9x machines where adding this "illegal trailing character" made the directory inaccessible from the regular file explorer.
Up until recently, you could do the same thing in the Windows Registry to make it so normal Windows tools (e.g. Regedit) couldn't view/modify certain entries. I believe it was still an issue in the last five~ years.
This all sounds like a wonderful way to write some truly annoying malware. I expect to see hidden mounts on SQL-escape-type-maliciously-named drives soon...
I understand your point; but I'm struggling to see how this could be weaponized. Keep in mind, that these Dos compatible drive letters need to map to a real NT path endpoint (e.g. a drive/volume); so it isn't clear how the malware could both have a difficult to scan Dos tree while also not exposing that same area elsewhere for trivial scanning.
> In other words, since RtlDosPathNameToNtPathName_U converts C:\foo to \??\C:\foo, then an object named C: will behave like a drive letter. To give an example of what I mean by that: in an alternate universe, RtlDosPathNameToNtPathName_U could convert the path FOO:\bar to \??\FOO:\bar and then FOO: could behave like a drive letter.
For some reason I remember that the original xbox 360 had "drive letters" which were entire strings. Unfortunately I no longer have access to the developer docs and now I wonder if my mind completely made this up. I think it was something like "Game:\foo" and "Hdd0:\foo".
Anybody who's had to look through files on multi-disc arrays knows exactly how weird the drive letters can get. Mount the ISOs of thirty six 8.5GB DVDs because someone thought it was a good idea to split zip a single archive into 7.99GB segments and things get very tricky in cmd. If you weren't in the habit of using several layers of quotation marks to separate everything you'll form it very quickly because the operators can be the same symbols as the drive letters, as shown in the article with the "+" example.
I remember vividly when a user couldn't access his smb drive from Windows because both his printer and also the computer's case came with one of these multi-cardreaders with n slots and the drive letters collided. That's when I learned that smb drive letters don't even come from the "global" pool of drive letters, because, and this is obvious in hindsight, they are a per-user affair (credentials and all that).
Even Microsoft appears to agree with you, given that drive letters are symlinks. It's basically legacy, there's just no plan or reasonable path forward that will remove them.
Not while it's mounted. This is akin to complaining that on Linux if you unplug a flash drive and plug in a different one that second drive could "steal" /mnt/sdb1 or whatever.
Which can be trivially mapped to directories for aliasing. Just like Linux.
Windows NT and UNIX are much more similar than many people realize; Windows NT just has a giant pile of Dos/Win9x compatibility baked on top hiding how great the core kernel design actually is.
> [ .. ] Inserting an USB drive before boot breaks booting.
Only if the machine's BIOS is configured to give bootable USB devices boot-order priority. So it's not about Linux -- in fact, the same thing would happen on a Windows machine.
Remember that in a properly configured Linux install, the boot partition is identified by UUID, not hardware identifier (in /etc/fstab). Consequently if you change a drive's hardware connection point, the system still boots.
You can fix the drive letter assignments at any time if they become a problem, or use a directory as a mount point if that's less troublesome. (Win-R, diskmgmt.msc)
I hope this article gets archived in a computer history, so people in the future can read how today's default operating system persisted in requiring its vict..., umm, users, to honor an archaic practice long past any imaginable justification, while free alternative operating systems don't have this handicap.
I regularly have this conversation with my end-user neighbor -- I explain that he has once again written his backup archive onto his original because he plugged in his Windows USB drives in the wrong sequence. His reply is, more or less, "Are computers still that backward?" "No," I reply, "Windows is still that backward."
The good news is that Linux is more sophisticated. The bad news is that Linux users must be more sophisticated as well. But this won't always be true.
Are Linux /dev device paths (originating from Unix) really much better? They're a pretty odd feature if you think about it. "Everything is a file", except only certain things can be files and at least by convention they only appear under /dev. Plan 9 takes the everything is a file concept to its logical conclusion and is much better designed.
Edit: Also /dev/sdX paths in Linux are not stable. They can and do vary across boot, since Linux 5.6.
> Are Linux /dev device paths (originating from Unix) really much better?
Not better at all, which is why Linux uses partition UUIDs to identify specific storage partitions, regardless of hardware identifiers. This isn't automatic, the user must make it happen, which explains why Linux users need to know more than Windows users (and why Linux adoption is stalled).
> Edit: Also /dev/sdX paths in Linux are not stable. They can and do vary across boot, since Linux 5.6.
Yes, true, another reason to use partition UUIDs.
> Plan 9 takes the everything is a file concept to its logical conclusion and is much better designed.
It's a shame that Plan 9 didn't get traction -- too far ahead of its time I guess.
VMS expects to be run as a cluster of machines with a single drive system. How that actually happens is “hidden” from user view, and what you see are “logicals”, which can be stacked on top of each other and otherwise manipulated by a user/process without affecting the underlying file system. The results can be insane in the hands of inexperienced folks. But that is where NT came from.
All true, all good points. Some day partitions and their unique UUIDs will be the sole valid identifiers. Then end users will have to be warned not to copy entire partitions including their (no longer unique) UUID. Sounds bizarre but I've had that exact conversation.
I remember when A and B were commonly used drive letters. C was a luxury. D was outright bourgeois.
But for some reason, drive letters starting with C feel completely natural, too. Maybe it's because C is also the first note in the most widely known musical scale. We can totally afford to waste two drive letters at the start, right?
On systems with a single floppy, drives A: and B: were two logical drives mapped to the same physical drive. This enabled you to (tediously) copy files from one diskette to another.
While original IBM PCs indeed may not have had HDDs, it did become a standard for PC XT, as early as 1983. Only the cheapest version were without a HDD by the end of the 1980s.
It's just whatever happens to end up there? That's why D was typically the CD-ROM: A was the first floppy drive, B the (typically absent) second floppy drive, C the only hard disk, and then D was the next free letter.
On my laptop, D is the SD card slot. On my desktop, it's the 2nd SSD.
We used to set our machines so the CD-ROM was always drive L. This way we always had 'room' to add HDs so there was no gap in the alphabetical sequence. Drive D - data drive, E - swapfile, etc.
Test and external drives (being temporary) were assigned letters further down than L. Sticking reasonably rigidly to this nomenclature avoided stuff-up such as cloning an empty drive onto one with data on it (cloning was a frequent activity).
Incidentally, this rule applied to all machines, a laptop with HD would have C drive and L as the CD-ROM. Machines with multiple CD-ROMs would be assigned L, M and so on.
On servers, D is commonly used to push data / vendor installations / other stuff you may want to backup separate from the OS off of the main OS drive C.
D usually refers to the second internal storage device these days. Either a second SSD, a large HDD, or an extra partition in your system disk. If you don't have any of those, a USB stick might get the D drive temporarily.
The NT paths are how the object manager refers to things. For example the registry hive HKEY_LOCAL_MACHINE is an alias for \Registry\Machine
https://learn.microsoft.com/en-us/windows-hardware/drivers/k...
In this way, NT is similar to Unix in that many things are just files part of one global VFS layout (the object manager name space).
Paths that start with drive letters are called a "DOSPath" because they only exist for DOS compatibility. But unfortunately, even in kernel mode, different sub systems might still refer to a DOSPath.
Powershell also exposes various things as "drives", pretty sure you could create your own custom drive as well for your custom app. For example, by default there is the 'hklm:\' drive path:
https://learn.microsoft.com/en-us/powershell/scripting/sampl...
Get-PSDrive/New-PSDrive
You can't access certificates in linux/bash as a file path for example, but you can in powershell/windows.
I highly recommend getting the NtObjectManager powershell module and exploring about:
https://github.com/googleprojectzero/sandbox-attacksurface-a...
ls NtObject:\
> You can't access certificates in linux/bash as a file path for example, but you can in powershell/windows.
I don't understand what you mean by this. I can access them "as a file" because they are in fact just files
I _suspect_ they mean that certs imported into MMC in Windows can be accessed at magic paths, but...yeah linux can do that because it skips the step of making a magical holding area for certs.
Windows is not limited to accessing partitions through drive letters either, it's just the existing convention.
You can mount partitions under directories just like you can in Linux/Unix.
PowerShell has Add-PartitionAccessPath for this:
> mkdir C:\Disk
> Add-PartitionAccessPath -DiskNumber 1 -PartitionNumber 2 -AccessPath "C:\Disk"
> ls C:\Disk
It will persist through reboots too.
Don't have to use PowerShell either, it's been available for ages through Disk Management. Right-click on a partition -> Change Drive Letter and Path -> Add -> Mount in following empty NCTS folder.
Only for NTFS (both source and dest) though, no exFAT shared drives under a folder mount or what have you. I think the same is actually true of ReFS for some reason.
When you create/format the partition in the GUI tools it'll actually ask if you want to assign a drive letter or mount as a path as well.
I just tried mounting a exFAT partition at "C:\exFAT" and it worked just fine.
Other way around. Try mounting E: in your exfat drive.
That's because some filesystems like NTFS expose necessary metadata for integration and some don't. FAT and exFAT do not.
NTFS mount points can be very handy for engineering around software that doesn't allow you to customize paths. I can choose VM disks with different performance or replication policies and stitch them together like I would on a *nix OS. It's very handy and only in rare occasions have I had applications "notice" it and balk.
What, excuse me, the fuck? I never knew one could do this. Thanks!
The cursedness of "€:\" is awesome. It's amazing how much more flexible the NT kernel is vs what's exposed to the user.
Very cursed, and the drive letter won't even be accessible under certain codepages.
Yeah only the DOS façade of Windows NT is well known. Under that skin lurks some pretty wild late-1980s concepts. One of the core things to understand is that a lot of the features are based on a reverse map of GUIDs to various actions, and resolution of these map entries pervades the UI. That's why you can put {hexspew} as the name of a shortcut on the Windows desktop and have it magically become a deep link to some feature that Windows doesn't otherwise let you create a shortcut to, and also why you can just add things to the control panel which doesn't seem like it would be an intentional feature. And these actions can be named symbols inside DLLs, so they can do literally anything the OS is capable of doing. This is also why Windows has always been ground zero for malware.
>so they can do literally anything the OS is capable of doing
Yea, over the years someone thought of something they wanted to do and then did it without a systematic consideration of what that level of power meant, especially as multi-user network connectivity and untrusted data became the norm.
> Drives with a drive-letter other than A-Z do not appear in File Explorer, and cannot be navigated to in File Explorer.
Well there goes my plan to replace all my drive letters with emojis :(
You would be limited to a fairly small subset of emojis, anyway: many (most?) of them are outside of the BMP so don’t fit into a single UTF-16 code unit, and some of the remaining ones are ordinary characters followed by an emoji style selector (U+FE0F), which doesn’t fit either.
From the article:
> Drives with a drive-letter other than A-Z do not appear in File Explorer, and cannot be navigated to in File Explorer.
Reminds me of the old-school ALT + 255 trick on Win9x machines where adding this "illegal trailing character" made the directory inaccessible from the regular file explorer.
Shhh… that’s how we hid the Duke Nukem installs on the boxen in the dorm computer lab.
Up until recently, you could do the same thing in the Windows Registry to make it so normal Windows tools (e.g. Regedit) couldn't view/modify certain entries. I believe it was still an issue in the last five~ years.
This all sounds like a wonderful way to write some truly annoying malware. I expect to see hidden mounts on SQL-escape-type-maliciously-named drives soon...
I understand your point; but I'm struggling to see how this could be weaponized. Keep in mind, that these Dos compatible drive letters need to map to a real NT path endpoint (e.g. a drive/volume); so it isn't clear how the malware could both have a difficult to scan Dos tree while also not exposing that same area elsewhere for trivial scanning.
I'm betting there's some badly written AV software out there which will crash on non-standard drive letters, allowing at least a bit of mayhem.
Wait until your learn about Alternate Data Streams…
> This all sounds like a wonderful way to write some truly annoying malware.
AFAIK you need admin priviledges to play with drives in Windows.
This is an interesting reference about how drive letters are stored in the Windows Registry: http://www.goodells.net/multiboot/partsigs.shtml
I never tried, but I wonder if you could use direct registry editing to create some really strange drive letters.
> In other words, since RtlDosPathNameToNtPathName_U converts C:\foo to \??\C:\foo, then an object named C: will behave like a drive letter. To give an example of what I mean by that: in an alternate universe, RtlDosPathNameToNtPathName_U could convert the path FOO:\bar to \??\FOO:\bar and then FOO: could behave like a drive letter.
For some reason I remember that the original xbox 360 had "drive letters" which were entire strings. Unfortunately I no longer have access to the developer docs and now I wonder if my mind completely made this up. I think it was something like "Game:\foo" and "Hdd0:\foo".
Anybody who's had to look through files on multi-disc arrays knows exactly how weird the drive letters can get. Mount the ISOs of thirty six 8.5GB DVDs because someone thought it was a good idea to split zip a single archive into 7.99GB segments and things get very tricky in cmd. If you weren't in the habit of using several layers of quotation marks to separate everything you'll form it very quickly because the operators can be the same symbols as the drive letters, as shown in the article with the "+" example.
Hmm. This seems like it could be abused rather hilariously (or not, depending on your perspective) by malware...
If the malware that exploits my machine also runs off the eggplant emoji drive, I'm becoming Amish.
Similar corner cases are the bedrock of security flaws.
If anyone adds this behaviour as a bet on a market about a future CVE or severity, can they add a link to the bet here?
Seems like a great way to hide a bunch of files from users for a malware payload
Windows drive letters are ridiculous. Use an external drive for e.g. video editing, its letter can be stolen by another drive, you can’t work anymore.
Only if the actual "drive letter" assigned to the drive is the special value for "auto".
Otherwise, the drive letter is allocated statically and won't be used by another volume.
I remember vividly when a user couldn't access his smb drive from Windows because both his printer and also the computer's case came with one of these multi-cardreaders with n slots and the drive letters collided. That's when I learned that smb drive letters don't even come from the "global" pool of drive letters, because, and this is obvious in hindsight, they are a per-user affair (credentials and all that).
I think the concept of drive letters is flawed.
Even Microsoft appears to agree with you, given that drive letters are symlinks. It's basically legacy, there's just no plan or reasonable path forward that will remove them.
Not while it's mounted. This is akin to complaining that on Linux if you unplug a flash drive and plug in a different one that second drive could "steal" /mnt/sdb1 or whatever.
People did complain about that, which is why on Linux today that mount would use the disk UUID or label instead.
So it’s fixed. What’s windows’ excuse? :-)
Windows also has uuids. E.g.:
Which can be trivially mapped to directories for aliasing. Just like Linux.
Windows NT and UNIX are much more similar than many people realize; Windows NT just has a giant pile of Dos/Win9x compatibility baked on top hiding how great the core kernel design actually is.
I think this article demonstrates that very well.
Linux is broken from this point of view. Inserting an USB drive before boot breaks booting .
Only if you have a broken kernel cmdline or fstab that references /dev/sd* instead of using the UUID=xyz or /dev/disk/by-id/xyz syntax.
Certainly doesn't for me. Skill issue.
> [ .. ] Inserting an USB drive before boot breaks booting.
Only if the machine's BIOS is configured to give bootable USB devices boot-order priority. So it's not about Linux -- in fact, the same thing would happen on a Windows machine.
Remember that in a properly configured Linux install, the boot partition is identified by UUID, not hardware identifier (in /etc/fstab). Consequently if you change a drive's hardware connection point, the system still boots.
You can fix the drive letter assignments at any time if they become a problem, or use a directory as a mount point if that's less troublesome. (Win-R, diskmgmt.msc)
This topic would make a good post on The Old New Thing.
This was a cool article. Learned something new today.
Now somebody will uses this to hide their malware, somehow...
I hope this article gets archived in a computer history, so people in the future can read how today's default operating system persisted in requiring its vict..., umm, users, to honor an archaic practice long past any imaginable justification, while free alternative operating systems don't have this handicap.
I regularly have this conversation with my end-user neighbor -- I explain that he has once again written his backup archive onto his original because he plugged in his Windows USB drives in the wrong sequence. His reply is, more or less, "Are computers still that backward?" "No," I reply, "Windows is still that backward."
The good news is that Linux is more sophisticated. The bad news is that Linux users must be more sophisticated as well. But this won't always be true.
Are Linux /dev device paths (originating from Unix) really much better? They're a pretty odd feature if you think about it. "Everything is a file", except only certain things can be files and at least by convention they only appear under /dev. Plan 9 takes the everything is a file concept to its logical conclusion and is much better designed.
Edit: Also /dev/sdX paths in Linux are not stable. They can and do vary across boot, since Linux 5.6.
> Are Linux /dev device paths (originating from Unix) really much better?
Not better at all, which is why Linux uses partition UUIDs to identify specific storage partitions, regardless of hardware identifiers. This isn't automatic, the user must make it happen, which explains why Linux users need to know more than Windows users (and why Linux adoption is stalled).
> Edit: Also /dev/sdX paths in Linux are not stable. They can and do vary across boot, since Linux 5.6.
Yes, true, another reason to use partition UUIDs.
> Plan 9 takes the everything is a file concept to its logical conclusion and is much better designed.
It's a shame that Plan 9 didn't get traction -- too far ahead of its time I guess.
This has (more or less) been covered before!
https://news.ycombinator.com/item?id=17652502
VMS expects to be run as a cluster of machines with a single drive system. How that actually happens is “hidden” from user view, and what you see are “logicals”, which can be stacked on top of each other and otherwise manipulated by a user/process without affecting the underlying file system. The results can be insane in the hands of inexperienced folks. But that is where NT came from.
All true, all good points. Some day partitions and their unique UUIDs will be the sole valid identifiers. Then end users will have to be warned not to copy entire partitions including their (no longer unique) UUID. Sounds bizarre but I've had that exact conversation.
I remember when A and B were commonly used drive letters. C was a luxury. D was outright bourgeois.
But for some reason, drive letters starting with C feel completely natural, too. Maybe it's because C is also the first note in the most widely known musical scale. We can totally afford to waste two drive letters at the start, right?
Oh bless you and your youngsterness. A and B, by convention, were reserved for floppy drives and C was typically the first hard drive.
On systems with a single floppy, drives A: and B: were two logical drives mapped to the same physical drive. This enabled you to (tediously) copy files from one diskette to another.
Hard drives were a luxury.
While original IBM PCs indeed may not have had HDDs, it did become a standard for PC XT, as early as 1983. Only the cheapest version were without a HDD by the end of the 1980s.
Many clones came without a HDD.
Sure, I can imagine that.
My first contact with PCs was in 1988 and they all had HDDs and were definitely not "IBM PC" but clones. That said, that's just my experience so YMMV.
D was typically a CD-ROM drive. So when CD-ROMs went the way of the dinosaurs, where did D go ? Is it always some kind of SYS drive nowadays ?
It's just whatever happens to end up there? That's why D was typically the CD-ROM: A was the first floppy drive, B the (typically absent) second floppy drive, C the only hard disk, and then D was the next free letter.
On my laptop, D is the SD card slot. On my desktop, it's the 2nd SSD.
"That's why D was typically the CD-ROM:"
We used to set our machines so the CD-ROM was always drive L. This way we always had 'room' to add HDs so there was no gap in the alphabetical sequence. Drive D - data drive, E - swapfile, etc.
Test and external drives (being temporary) were assigned letters further down than L. Sticking reasonably rigidly to this nomenclature avoided stuff-up such as cloning an empty drive onto one with data on it (cloning was a frequent activity).
Incidentally, this rule applied to all machines, a laptop with HD would have C drive and L as the CD-ROM. Machines with multiple CD-ROMs would be assigned L, M and so on.
C: is the boot partition with the DoubleSpace driver, D: is the compressed volume.
Stacker compressed volume ;)
On servers, D is commonly used to push data / vendor installations / other stuff you may want to backup separate from the OS off of the main OS drive C.
D usually refers to the second internal storage device these days. Either a second SSD, a large HDD, or an extra partition in your system disk. If you don't have any of those, a USB stick might get the D drive temporarily.