• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

What will windows do if i have 27 drives in a PC?

Page 2 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
While Linux can have plenty of /dev/sd* names, they are just enumeration and for mounting filesystems one should prefer persistent and unique names. Similarly, Windows assigns its drive letters by automatic enumeration, but lets you change a letter of a volume (to make it semipersistent). Sadly, moving Windows away from "C:" is not among the easy operations and too many drive letters get written / hardcoded into the registry / applications to prevent dynamic changes. Pathetic.

While one machine may not have N drives DAS, it is easy with SAN. Add multipathing and numbers do grow. I have four paths per LUN ... (ok, device names and volume names are two different things).
 
I find it funny that your two first statements are contradictory. How can it work just fine with mount points if MS won't ditch drive letters for compatibility? I can understand keeping C:\ as a reference to the system volume, but everything else can be a mount point and no app really cares. Some get confused about drive space because they assume 1 volume per-letter and that each directory on a drive has the same free/used space as the root drive, but that's a bug in that app that should be fixed.



And sadly, they don't work exactly like unix mount points. They're close, but you're restricted to NTFS so it really can't apply to thumb drives until MS removes that restriction. Linux lets me mount any filesystem anywhere and I don't see a reason for Windows not to be able to do the same.

You can find it funny all you want, but that's because you don't get what I said.

Some drive letter must exist (c🙂, but everything else can be done with mount points. The two statements are not contradictory in any sense.
 
You can find it funny all you want, but that's because you don't get what I said.

Some drive letter must exist (c🙂, but everything else can be done with mount points. The two statements are not contradictory in any sense.

I may have taken it more extreme than you meant it, but I still don't think it works that well. The installer still doesn't let you use them so directories like \Users and Program Files can't be mounted on another volume easily, they're still restricted to NTFS on NTFS and local only so you can't use them with network or FAT thumb drives.

So they really only work for a very limited subset of "everything else".
 
For what it is worth, Windows doesn't use drive letters under the hood either.

My C drive is this:

\\?\Volume{b6f1599e-5001-11df-b97f-806e6f6e6963}\
C:\

Or simplified as

\Device\HarddiskVolume3

You can use mountvol at the command line to see these / disable auto mounts / mount to directories.

drive letters are there for legacy use basically.
 
For what it is worth, Windows doesn't use drive letters under the hood either.

My C drive is this:

\\?\Volume{b6f1599e-5001-11df-b97f-806e6f6e6963}\
C:\

Or simplified as

\Device\HarddiskVolume3

You can use mountvol at the command line to see these / disable auto mounts / mount to directories.

drive letters are there for legacy use basically.

I wouldn't call something that is the primary access method legacy. Once MS starts mounting CIFS shares, USB drives, etc as directories under the system root then they'll be legacy. I hadn't realized the UUID paths were user accessible until now, but given that those aren't anything a user would want to use let alone are presented to them in any way I can't see how those can be considered anything but an internal implementation detail.
 
I wouldn't call something that is the primary access method legacy. Once MS starts mounting CIFS shares, USB drives, etc as directories under the system root then they'll be legacy. I hadn't realized the UUID paths were user accessible until now, but given that those aren't anything a user would want to use let alone are presented to them in any way I can't see how those can be considered anything but an internal implementation detail.

Not sure about CIFS yet but:

USB:

\\?\Volume{e5c749ad-f06a-11e1-be55-000c2992a069}\
*** NO MOUNT POINTS ***

\\?\Volume{e5c749ad-f06a-11e1-be55-000c2992a069}\
C:\Users\Administrator\Desktop\512mb\

As FAT also btw. CDROM also works
 
Not sure about CIFS yet but:

USB:

\\?\Volume{e5c749ad-f06a-11e1-be55-000c2992a069}\
*** NO MOUNT POINTS ***

\\?\Volume{e5c749ad-f06a-11e1-be55-000c2992a069}\
C:\Users\Administrator\Desktop\512mb\

As FAT also btw. CDROM also works

I thought of CDs after posting that, but I didn't think FAT did. I wonder if that's a new addition? But they're still not done like that by default meaning drive letters are far from legacy since they're the default access method.
 
Back
Top