Comment by Arainach
Comment by Arainach 3 days ago
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.
Comment by Arainach 3 days ago
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.
I think this article demonstrates that very well.
> [ .. ] 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.
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.
> Only if you have an old-style kernel cmdline or fstab that references /dev/sd* instead of using the UUID=xyz or /dev/disk/by-id/xyz syntax.
Fixed that for you. It used to be normal to use the device path (/dev/hd* or /dev/sd*) to reference the filesystem partitions. Using the UUID or the by-id symlink instead is a novelty, introduced precisely to fix these device enumeration order issues.
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? :-)