Are we finally ditching drive letters?

JAM83 · Jul 5, 2021

I actually want to keep the drive letters. It makes things easier for me

BunnyJ · Jul 5, 2021

JMedlock83 said:
I actually want to keep the drive letters. It makes things easier for me

I agree and I'm so used to using letters. Keep it simple..

Winuser · Jul 5, 2021

I don't see a problem with drive letters. My very first computer was a Atari 800 XL with dual 5 1/4" disk drives and I think it used drive letters. After the Arari computers I had a Tandy (if I remember right) 1000 RXS running Deskmate and that used drive letters. My first Windows computer was a Packard Bell 386 running Windows 3.1 for Work Group and that used drive letters. AS far as I know all of my computers used drive letters. Is there a advantage of not using drive letters?

JAM83 · Jul 5, 2021

Winuser said:
I don't see a problem with drive letters. My very first computer was a Atari 800 XL with dual 5 1/4" disk drives and I think it used drive letters. After the Arari computers I had a Tandy (if I remember right) 1000 RXS running Deskmate and that used drive letters. My first Windows computer was a Packard Bell 386 running Windows 3.1 for Work Group and that used drive letters. AS far as I know all of my computers used drive letters. Is there a advantage of not using drive letters?

I thought Atari was a gaming console? hehehehehehe

Try3 · Jul 5, 2021

hsehestedt said:
The interesting thing to me is that some commands and some operations within the Windows GUI will accept those references to a drive, while many others do not. Most notably, at least for me personally, is the lack of support for these by robocopy. If robocopy would accept those references it would make it so much easier than having to jump through hoops to determine what drive letter was assigned to a device.

You can use [batch] scripting to retrieve the current drive letter based on knowing the drive's name/label. I use it as a subroutine for such tasks as backing up with RoboCopy.

If you'd use it, I'll post the script for you.

Denis

rumplestiltskin · Jul 6, 2021

I use SynbackSE but if you're looking for a free alternative, there's FreeSync which seems to do much of what SyncBackSE does. Like SyncBack, FreeSync supports volume names or serial IDs instead of drive letters (your option). So drive letters prove to be irrelevant and even harmful yet again.

BunnyJ · Jul 6, 2021

I was giving this a bit of thought. In Windows you have access to the command line IE DOS and many still make use of it for programming etc. In order to get to my source code I have to change drives and using letters is the only way to go, IMO. For example if I'm using Visual Studio I run the python code in Command Line.. without letters it would be a pain to dot that

rumplestiltskin · Jul 6, 2021

BunnyJ said:
I was giving this a bit of thought. In Windows you have access to the command line IE DOS and many still make use of it for programming etc. In order to get to my source code I have to change drives and using letters is the only way to go, IMO. For example if I'm using Visual Studio I run the python code in Command Line.. without letters it would be a pain to dot that

So how do you handle drive letters changing (as they are wont to do)? I don't necessarily mean programming but within the compiled program itself?

BunnyJ · Jul 6, 2021

rumplestiltskin said:
So how do you handle drive letters changing (as they are wont to do)? I don't necessarily mean programming but within the compiled program itself?

I go to the location of the program I coded and run it. For example if I have my code on my H drive and in Python I go to
H:
CD Python
And to run it I use
python test.py or
test.exe

larc919 · Jul 6, 2021

If it ain't broke, don't fix it! I believe there's too much thinking that things sometimes need to be changed just because they've been around a long time. Drive letters were used on the first computer I ever bought, but that doesn't mean there's anything wrong with it. Maybe there's somebody who can come up with something logically better than drive letters, but it's beyond me.

Winuser · Jul 7, 2021

JMedlock83 said:
I thought Atari was a gaming console? hehehehehehe

They did make computers. They also made printer for their computers that used small ink pens for the ink supply.

Wynona · Jul 30, 2021

rumplestiltskin said:
I write this as a former Mac user who has fired Apple (for a number of reasons unrelated to this thread).

In macOS, all (visible) volumes mount on the Desktop automatically whether they're HFS+, APFS, FAT, NTFS; and whether the protocol is Firewire, USB, or eSata, etc. As long as the Mac has the appropriate wired connection, it's a done deal. Any apps that utilize those mounted volumes can and will access them no matter when they are mounted or even if the wired connection changes (ie, move the drive from an eSata enclosure to a USB dock). (I know that NTFS is not writable without add'l software but that's unrelated to this post.)

In Windows10, we have drive letters that, except for internal permanently mounted volumes, are assigned drives letters that are ephemeral even if specifically assigned during the formatting process if another drive mounts earlier and grabs that drive letter. As many apps rely upon drive letters in their preferences to locate their data files, it is not unusual for an app to find...or, rather, not find its data files.

"Drive letters" is an enormously stupid concept that hangs on from 1981. I expect this is because there are old farts (possibly older than I) who just can't let go of what we politely call legacy applications and, accordingly, developers keep plodding along because they don't want to be dragged over the coals for abandoning the base.

Now, there are some developers who do provide alternatives to drive letters; I'll shout out to 2BrightSparks' SyncBackSE as a (no pun intended) shining example of this. The app provides a choice to use drive letters, the name of the volume or the unique serial ID of the volume so if your backup drive appears as "L:" rather than "J:", the app is happy and proceeds. (Likewise, if another drive mounts as "J:", SyncBackSE won't treat it as a destination backup drive and erase it accidentally!}

Now, before a learned guru takes me to task (and I really do have tremendous respect for those who have already provided system-saving advice to me here!), I do know about not using a drive letter and accessing the volume through a shortcut but it's not mounted on the Desktop; and there lies the crux of the issue: This is a kludge, a clumsy workaround to a problem that Microsoft knows how to solve. The volumes have names (if only we would use them - and I do as a former Mac user) and, more importantly, have unique serial numbers that stay unique. Carbon Copy Cloner is an example of a Mac app that may be configured to use the unique volume ID when cloning; it will do this for both source and destination. Apple does not have a patent on this.

Microsoft needs to implement volumes on the Desktop automatically, advise developers to migrate their apps to the new paradigm (name/serial ID) and, in so doing, provide Windows users with the convenience that Mac users have had since day one.

As far as I'm concerned, it ain't broke and I ain't agonna try to fix it!

I like Windows just fine the way it is.

johnlgalt · Jul 30, 2021

rumplestiltskin said:
I write this as a former Mac user who has fired Apple (for a number of reasons unrelated to this thread).

In macOS, all (visible) volumes mount on the Desktop automatically whether they're HFS+, APFS, FAT, NTFS; and whether the protocol is Firewire, USB, or eSata, etc. As long as the Mac has the appropriate wired connection, it's a done deal. Any apps that utilize those mounted volumes can and will access them no matter when they are mounted or even if the wired connection changes (ie, move the drive from an eSata enclosure to a USB dock). (I know that NTFS is not writable without add'l software but that's unrelated to this post.)

In Windows10, we have drive letters that, except for internal permanently mounted volumes, are assigned drives letters that are ephemeral even if specifically assigned during the formatting process if another drive mounts earlier and grabs that drive letter. As many apps rely upon drive letters in their preferences to locate their data files, it is not unusual for an app to find...or, rather, not find its data files.

"Drive letters" is an enormously stupid concept that hangs on from 1981. I expect this is because there are old farts (possibly older than I) who just can't let go of what we politely call legacy applications and, accordingly, developers keep plodding along because they don't want to be dragged over the coals for abandoning the base.

Now, there are some developers who do provide alternatives to drive letters; I'll shout out to 2BrightSparks' SyncBackSE as a (no pun intended) shining example of this. The app provides a choice to use drive letters, the name of the volume or the unique serial ID of the volume so if your backup drive appears as "L:" rather than "J:", the app is happy and proceeds. (Likewise, if another drive mounts as "J:", SyncBackSE won't treat it as a destination backup drive and erase it accidentally!}

Now, before a learned guru takes me to task (and I really do have tremendous respect for those who have already provided system-saving advice to me here!), I do know about not using a drive letter and accessing the volume through a shortcut but it's not mounted on the Desktop; and there lies the crux of the issue: This is a kludge, a clumsy workaround to a problem that Microsoft knows how to solve. The volumes have names (if only we would use them - and I do as a former Mac user) and, more importantly, have unique serial numbers that stay unique. Carbon Copy Cloner is an example of a Mac app that may be configured to use the unique volume ID when cloning; it will do this for both source and destination. Apple does not have a patent on this.

Microsoft needs to implement volumes on the Desktop automatically, advise developers to migrate their apps to the new paradigm (name/serial ID) and, in so doing, provide Windows users with the convenience that Mac users have had since day one.

I actually explored trying to make use of the VolumeID for a few small things I do, and it works, and it works well. But some apps are simply not able to make use of the VolumeID, and it is irritating- otherwise I couldn't care less if Google Drive is F today and H tomorrow, whereas my USB Device is G today and F tomorrow.

It is, indeed, absolutely stupid. Linux works much the same manner. Only Windows sticks to arbitrarily assigned drive letter.

If there was a way I could force drive letter assignment via VolumeID in and of itself in Windows, even *that* would be mostly enough to work for me. But noooooooooooo, I have to reply on the whim of the OS as to which drive is assigned what where.

It got to the point where I would make sure that my system drive was always installed to the first listed drive in diskpart, so it would stay at C, etc. But that got hairy on my last rig, as the SATA III ports were from a separate chipset tacked onto the board, made by Marvell, so diskpart always saw those drives *after* the drives attached to the SATA II ports (which, naturally being slower than SATA III, were not optimal choices for OS installation). The SATA II drives were listed sequentially before the Marvell SATA III drives, and then came the Blu-Ray RW - only whenever I cleanly installed Windows, upon reboot, sometimes the drives were C, D E and BDRW got assigned F and sometimes it was C, BDRW assigned to D, then E and F. And this occurred completely randomly, too.

Most annoying thing in the world.

ICIT2LOL · Aug 30, 2021

Personally, I cannot see why drive numbers or letters matters why make it more complicated by taking them away?? I am not that tech-savvy so any change to the current drive identification will make it as I said just that bit more complicated.

rumplestiltskin · Aug 30, 2021

If Microsoft would handle drives the way Apple does, then they would mount on the Desktop automatically with the name they were assigned when formatted. Users would then be aware that drive names are significant. In macOS, there are apps (ie, TimeMachine, Carbon Copy Cloner) that utilize the unique ID because you wouldn't want to overwrite a drive erroneously identically named as a backup destination. Letters are worthless if we can only accept that a drive's name could/should be unique. In Windows, SyncBackSE may be told to use names or unique IDs in place of drive letters (which change willy-nilly).

Microsoft is, frankly, just being lazy. If you have an app which relies upon a drive letter and, when it changes unwarranted resulting in data loss, you'll be right with me.

BunnyJ · Aug 30, 2021

No thanks.. I want the current format/style. If I want what Apple does.. well, I'll get a Mac. But you don't see me doing that. As a programmer I find it so easy to use drive letters in the command line interface to run programs and test code. I sure don't need any more dummbing down of my OS.

jbcarreon123 · Aug 30, 2021

rumplestiltskin said:
If Microsoft would handle drives the way Apple does, then they would mount on the Desktop automatically with the name they were assigned when formatted. Users would then be aware that drive names are significant. In macOS, there are apps (ie, TimeMachine, Carbon Copy Cloner) that utilize the unique ID because you wouldn't want to overwrite a drive erroneously identically named as a backup destination. Letters are worthless if we can only accept that a drive's name could/should be unique. In Windows, SyncBackSE may be told to use names or unique IDs in place of drive letters (which change willy-nilly).

Microsoft is, frankly, just being lazy. If you have an app which relies upon a drive letter and, when it changes unwarranted resulting in data loss, you'll be right with me.

No thanks. I want an scheme that works without any commands in bash (or Console on Mac) to make the drive show.
As a batch scripter, I prefer to use drive letters than /mnt/drive/disk/usb/0 (or what shorter or longer than that).
Also, WSL rely on drive letters to list dir /mnt/c

rumplestiltskin · Aug 30, 2021

jbcarreon123 said:
No thanks. I want an scheme that works without any commands in bash (or Console on Mac) to make the drive show.
As a batch scripter, I prefer to use drive letters than /mnt/drive/disk/usb/0 (or what shorter or longer than that).
Also, WSL rely on drive letters to list dir /mnt/c

...and that (what you want) is exactly the way it works on a Mac...without Bash or Console or anything. Certainly providing automatic mounting on the Desktop of USB-connected drives wouldn't preclude the use of drive letters; I would imagine you'd click a checkbox to display letters (on uncheck that box if you prefer).

I think some of you who are voicing a preference for drive letters are failing to see how they aren't necessary if the file system would only advance beyond what you had in 1981.

None of what we've written in this thread would make me go back to a Mac as I have some serious issues with Apple that won't be fixed until the Macintosh division is spun off and Tim Cook is shown the door (and who sees that happening, eh?). Nevertheless, some aspects of macOS are better than WindowsOS (ie, Discovery over IP). It doesn't make one an Apple fanbois to ask MS to copy good Apple stuff; after all, they've done that with much of the UI since...umm...about forever.

PerpetualCycle · Aug 30, 2021

You could get rid of them I suppose, but for one reason. Safely eject drive. Sometimes external drives are only unique by drive letter. And if you have multiple external drives mounted, sometimes it doesn't show you the drive letter or name! And safely remove drive is it's own entity on the taskbar.

Since Windows is recycling ideas from Apple, it would be nice if they implemented their idea of right clicking on the drive and being able to choose safely remove from the context menu (perhaps after going to "show more options"

). I mean how hard is that, it is the logical and sensible thing to do. Then they could get rid of the stupid taskbar "safely remove" thingy.

BunnyJ · Aug 30, 2021

rumplestiltskin said:
...and that (what you want) is exactly the way it works on a Mac...without Bash or Console or anything. Certainly providing automatic mounting on the Desktop of USB-connected drives wouldn't preclude the use of drive letters; I would imagine you'd click a checkbox to display letters (on uncheck that box if you prefer).

I think some of you who are voicing a preference for drive letters are failing to see how they aren't necessary if the file system would only advance beyond what you had in 1981.

None of what we've written in this thread would make me go back to a Mac as I have some serious issues with Apple that won't be fixed until the Macintosh division is spun off and Tim Cook is shown the door (and who sees that happening, eh?). Nevertheless, some aspects of macOS are better than WindowsOS (ie, Discovery over IP). It doesn't make one an Apple fanbois to ask MS to copy good Apple stuff; after all, they've done that with much of the UI since...umm...about forever.

Thanks.. but no thanks. If I want to use a Mac.. I'll get a Mac. But I like Windows and how it works.