- Local time
- 3:48 PM
- Posts
- 37
- OS
- Win10 Home
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.
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.
My Computer
System One
-
- OS
- Win10 Home
- Computer type
- PC/Desktop
- Manufacturer/Model
- Lenovo
- CPU
- Core i9-10900K
- Motherboard
- Lenovo 3715
- Memory
- 16GB
- Graphics Card(s)
- RTX 2080
- Sound Card
- motherboard
- Monitor(s) Displays
- Viewsonic VG2755-2K
- Screen Resolution
- 2560x1440