Windows 10 May 2019 update blocked for anyone using USB or SD storage

If you really want to install the update now, you'll have to unplug your drives.

Read the whole story

 

[Ministry of Truth and Factoids]

Perhaps it's a combination of "discovered at the last minute" and the "whoops, there went your files" issue that hit with the October 2018 update. Better to be faced with this than people livid that Windows was installed on the wrong drive because of the drive letter shuffle.

Each drive has a DiskID, are their new coders so stupid, they were born in 1999 and have no clue?

The code should reference each drive via the DiskID.

How do we update the 32gb laptops/surface machines with little space, when we cannot put the update data on an external usb stick, and install/update should not require the extra space for the many size gig update files.

MS should have ability to update from USB, or update from NET, dynamically, one 'app' or component at a time. We dont need to store 2x the update files on disk, then delete source files, just do the equivalent of a unzip -x USB:/source/files/ -dest BOOTI/windows/

 

[cwsars]

Quote: "The reason for blocking the update is that it appears to be prone to shuffling the drive letters assigned to USB and SD storage devices. In other words, while your USB drive might show up as "" now, it could end up getting renamed to "E:" after upgrading to 1903. Fortunately, there is a straightforward workaround: unplug the drives and remove the memory card ..."

I have a better workaround -- eliminate drive letters, which date back to DOS and at the very least represent an embarrassment in modern times. The presence of drive letters in Windows 10 only tells us how old the oldest code in Windows is. Drive letters are to a modern operating system what a disfiguring congenital birthmark would be in a person.

No other modern operating system recognizes, or relies on, drive letters. Before anyone mentions OS/2, I emphasize that I specified "modern operating system".

I can't tell you how many times I've heard from Windows 10 end users who cannot reliably back up their systems because some external storage devices are automatically assigned one drive letter, some another, with no predictable pattern or reliability. What Windows won't do is assign or accept a *user-defined name* for a storage device, which would solve this issue once and for all.

This is how Linux/Unix deals with this issue. Just saying.

It amazes me how *nix zealots pretend drive letters are such a major problem but can literally give zero concrete reasons why it's a problem other than it's not how *nix does it.

Does "Windows 10 May 2019 update blocked for anyone using USB or SD storage." sound familiar? (It's the title of this article which you are posting to.)

First of all, Skippy, the codebase for *nix defacto dates back to 1969, so let's not pretend it's all that modern. How *nix handles everything as a file isn't all that special in the scheme of things and in some cases it's a huge detriment and there's kludges in the Linux kernel to get around that that make Microsoft's userland kludges for legacy software look pedestrian.

I'd love to review an example of what you consider to be an extra-pedestrian Linux kludge.

Please provide a link to the specific source code.

Once drive letters are set on permanently and semi-permanently connect drives Windows assigns the same ones every reboot unless something drastic happens like, you know, functionally reinstalling the operating system.

Or you install the May 2019 Windows patch?
Or you update a device driver, and the system bus topology ordering changes?

Unix originated on PDP mainframes and became popular on Sun and HP-PA hardware, which tended to use OpenFirmware rather than a PC BIOS and almost always exhibited stable system bus topology ordering. (To be fair, EFI in modern PCs could actually do better, but legacy compatibility with the BIOS world makes that complex.)

With x86-based hardware, flavors of Unix/Linux have added either disk-partition based drive labelling, or a UUID-to-device ordering held on the root filesystem, or both. This allows the devices to be enumerated consistently so that /etc/mounts doesn't break.

 

[jmauro]

WinNT architecture dates to the mid-1990s and was a near total rewrite of how Windows works with no legacy DOS code. (In fact, it's my understanding WinNT is closer to VMS and OS/2 than DOS.) The quality of Microsoft's implementation of WinNT can be debated, but the underlying theoretical framework is an impressive technical feat.

WinNT was designed in the 1980's by Dave Cutler, who designed VMS so the similarity isn't that unexpected. He's been pretty up front that the design strategy of NT was to improve on the VMS design.

The issue though is while NT 3.1 was a complete clean room redesign, starting with 3.51, Microsoft started bolting on parts of DOS and DOS-based Windows systems kludging the whole thing. It got worse during the Windows 2000 era, and we're still stuck with a lot of those decisions and merging due to Microsoft not wanting to leave anyone behind. They learned their lesson from the OS/2 joint-venture with IBM.

 

[lewax00]

So what you're saying is...I can just delay the update indefinitely by plugging in a USB drive?

It’s weird. Your witty comment on how to regain control over the updates gets “all the upvotes”, yet posts about Win7 users that don’t want auto-updates get “all the downvotes”.

In the end, I’m glad we all agree on one thing: MS QA is horrid.

The difference is security updates. I'm still accepting those, I just don't want the "feature" updates, because every freaking one breaks something and wastes my time trying to figure out how to fix it. And all I get in return is a feature I never wanted, that sometimes replaces a perfectly good feature with a worse one.

Example anecdote: last one screwed up my audio config (my microphone just stopped working completely...turned out for some reason all applications were suddenly forbidden from accessing it in security settings)...and two of my friends also had audio problems on that update. But each one of us had a different audio problem. And AFAIK we all have simple setups, just stereo speakers and a headset (and generally just switching between them depending on the situation), so it's not like we're some weird edge-case.

But Windows 7 doesn't really have much in the way of feature updates, it's mostly bug fixes and security updates. Avoiding those is a different story.

 

[Leguleius1]

So a few times in my period as the business partner in charge of hiring / orchestrating the IP people in a former job, I had to be in charge of roll out and testing of a major Windows "SP" update that was the equivalent of a full OS update. W2K SP4 and XP SP2 & 3.

The IP guys were careful in testing these with all our custom software. On each occasion we had to go to the software guys for some customization to fix things that broke with the SP update.

I've been saying for years that having Windows 10 on a cadence to push the equivalent of that kind of OS update, again the essential basics of which would be in inplace OS upgrade, twice a year is just too fucking much.

Every time. Every damn time there is something. And with Windows home users completely helpless to prevent it, its getting a little old. They need to dial it back to once a year and give themselves a full 6 months of testing so that these updates are perfect every time.

 

[Wickwick]

So a few times in my period as the business partner in charge of hiring / orchestrating the IP people in a former job, I had to be in charge of roll out and testing of a major Windows "SP" update that was the equivalent of a full OS update. W2K SP4 and XP SP2 & 3.

The IP guys were careful in testing these with all our custom software. On each occasion we had to go to the software guys for some customization to fix things that broke with the SP update.

I've been saying for years that having Windows 10 on a cadence to push the equivalent of that kind of OS update, again the essential basics of which would be in inplace OS upgrade, twice a year is just too fucking much.

Every time. Every damn time there is something. And with Windows home users completely helpless to prevent it, its getting a little old. They need to dial it back to once a year and give themselves a full 6 months of testing so that these updates are perfect every time.

I don't really care how often they push updates as long as they don't break shit. Google pushes updates to Chrome (and Chrome OS) more often flawlessly. The difference in complexity is obvious but it's more philosophical than that.

Internally, Microsoft can work on a feature update as long as they want. They should focus on extensive regression testing against as many targets as they can and spend time divorcing that update from other bits of code (refactor!). Hell, they can "shadow install" updates on active Windows install in the wild just to see if that process craps out (don't give it actual authority!).

And at the end of the day, when the features work feel free to ship twice per year. Or hell, with the monthly security patch. If shit doesn't break, why not upgrade all the time?

 

[Jooquily4]

Windows updates can do strange things (and can be done incorrectly, leaving a future trap for the unwary)...I have watched a Windows update move the recovery partition to an entirely different physical drive. If it does this, that means a successful boot is dependent on TWO drives, not just one. Very bizarre. I've gotten into the habit of checking the drive partitions after every major version update, just to make sure that the install was done entirely to a single physical drive.

 

[Adreaver]

So I bought the cheapest HP windows laptop available 1.5 years ago with 32 GB internal memory. Works fine for the simple tasks we give it. Not to long ago I had to buy a USB stick so that I could download and install the last Windows update because internal storage was insufficient to make it all work, even with very limited software installed. I hope they fix this glitch so I can access patches etc relatively soon!

Maybe you should just upgrade your internal storage?

Unless its embedded (in which case you can't do it at all and you should just stop reading), it should be a completely trivial upgrade. Find the service manual for the laptop (easily available on HP's support site, and for laptops far older than that), determine what type of drive it is (m.2 SATA, m.2 NVME, mSATA, or 2.5" SATA), buy a replacement with more capacity from Amazon, Newegg, or similar (likely at $50 or less for ~500GB), and you will never need to worry about that issue again.

 

[Jognt]

So what you're saying is...I can just delay the update indefinitely by plugging in a USB drive?

It’s weird. Your witty comment on how to regain control over the updates gets “all the upvotes”, yet posts about Win7 users that don’t want auto-updates get “all the downvotes”.

In the end, I’m glad we all agree on one thing: MS QA is horrid.

The difference is security updates. I'm still accepting those, I just don't want the "feature" updates, because every freaking one breaks something and wastes my time trying to figure out how to fix it. And all I get in return is a feature I never wanted, that sometimes replaces a perfectly good feature with a worse one.

Example anecdote: last one screwed up my audio config (my microphone just stopped working completely...turned out for some reason all applications were suddenly forbidden from accessing it in security settings)...and two of my friends also had audio problems on that update. But each one of us had a different audio problem. And AFAIK we all have simple setups, just stereo speakers and a headset (and generally just switching between them depending on the situation), so it's not like we're some weird edge-case.

But Windows 7 doesn't really have much in the way of feature updates, it's mostly bug fixes and security updates. Avoiding those is a different story.

I meant Win7 users that avoid win10 due to the forced updates. I can’t imagine anyone ignoring security updates regardless of the platform.

 

[lewax00]

So what you're saying is...I can just delay the update indefinitely by plugging in a USB drive?

It’s weird. Your witty comment on how to regain control over the updates gets “all the upvotes”, yet posts about Win7 users that don’t want auto-updates get “all the downvotes”.

In the end, I’m glad we all agree on one thing: MS QA is horrid.

The difference is security updates. I'm still accepting those, I just don't want the "feature" updates, because every freaking one breaks something and wastes my time trying to figure out how to fix it. And all I get in return is a feature I never wanted, that sometimes replaces a perfectly good feature with a worse one.

Example anecdote: last one screwed up my audio config (my microphone just stopped working completely...turned out for some reason all applications were suddenly forbidden from accessing it in security settings)...and two of my friends also had audio problems on that update. But each one of us had a different audio problem. And AFAIK we all have simple setups, just stereo speakers and a headset (and generally just switching between them depending on the situation), so it's not like we're some weird edge-case.

But Windows 7 doesn't really have much in the way of feature updates, it's mostly bug fixes and security updates. Avoiding those is a different story.

I meant Win7 users that avoid win10 due to the forced updates. I can’t imagine anyone ignoring security updates regardless of the platform.

I assumed you meant Windows 7 users that disable Windows Update because they don't want any automatic updates (because I have certainly seen those around in the comments section too).

But that's literally what staying on 7 gets you in the long-term though (well, not that long at this point):

Microsoft[/url]":27eh3eew]After January 14, 2020, Microsoft will no longer provide security updates or support for PCs running Windows 7.

 

[Voldenuit]

So I bought the cheapest HP windows laptop available 1.5 years ago with 32 GB internal memory. Works fine for the simple tasks we give it. Not to long ago I had to buy a USB stick so that I could download and install the last Windows update because internal storage was insufficient to make it all work, even with very limited software installed. I hope they fix this glitch so I can access patches etc relatively soon!

Maybe you should just upgrade your internal storage?

Unless its embedded (in which case you can't do it at all and you should just stop reading), it should be a completely trivial upgrade. Find the service manual for the laptop (easily available on HP's support site, and for laptops far older than that), determine what type of drive it is (m.2 SATA, m.2 NVME, mSATA, or 2.5" SATA), buy a replacement with more capacity from Amazon, Newegg, or similar (likely at $50 or less for ~500GB), and you will never need to worry about that issue again.

If they bought the 'cheapest hp windows laptop' with 32 GB NAND, it's probably a hp stream 11 or 13, which not only had the NAND soldered onto the motherboard, it adds insult to injury by using eMMC instead of a SATA or NVMe protocol.

 

[Adreaver]

So I bought the cheapest HP windows laptop available 1.5 years ago with 32 GB internal memory. Works fine for the simple tasks we give it. Not to long ago I had to buy a USB stick so that I could download and install the last Windows update because internal storage was insufficient to make it all work, even with very limited software installed. I hope they fix this glitch so I can access patches etc relatively soon!

Maybe you should just upgrade your internal storage?

Unless its embedded (in which case you can't do it at all and you should just stop reading), it should be a completely trivial upgrade. Find the service manual for the laptop (easily available on HP's support site, and for laptops far older than that), determine what type of drive it is (m.2 SATA, m.2 NVME, mSATA, or 2.5" SATA), buy a replacement with more capacity from Amazon, Newegg, or similar (likely at $50 or less for ~500GB), and you will never need to worry about that issue again.

If they bought the 'cheapest hp windows laptop' with 32 GB NAND, it's probably a hp stream 11 or 13, which not only had the NAND soldered onto the motherboard, it adds insult to injury by using eMMC instead of a SATA or NVMe protocol.

I have always maintained that you will pay a given minimum amount for tech purchases.

You can pay up front in dollars for better hardware.

You can pay down the road in dollars for earlier replacements and upgrades.

You can pay a little bit at a time in time spent resolving issues that would have been avoided by buying something a little better.

Or you can pay in frustration/lost productivity by not having things work properly.

But you will ALWAYS pay, one way or another.

 

[dodexahedron]

So a few times in my period as the business partner in charge of hiring / orchestrating the IP people in a former job, I had to be in charge of roll out and testing of a major Windows "SP" update that was the equivalent of a full OS update. W2K SP4 and XP SP2 & 3.

The IP guys were careful in testing these with all our custom software. On each occasion we had to go to the software guys for some customization to fix things that broke with the SP update.

I've been saying for years that having Windows 10 on a cadence to push the equivalent of that kind of OS update, again the essential basics of which would be in inplace OS upgrade, twice a year is just too fucking much.

Every time. Every damn time there is something. And with Windows home users completely helpless to prevent it, its getting a little old. They need to dial it back to once a year and give themselves a full 6 months of testing so that these updates are perfect every time.

I don't really care how often they push updates as long as they don't break shit. Google pushes updates to Chrome (and Chrome OS) more often flawlessly. The difference in complexity is obvious but it's more philosophical than that.

Internally, Microsoft can work on a feature update as long as they want. They should focus on extensive regression testing against as many targets as they can and spend time divorcing that update from other bits of code (refactor!). Hell, they can "shadow install" updates on active Windows install in the wild just to see if that process craps out (don't give it actual authority!).

And at the end of the day, when the features work feel free to ship twice per year. Or hell, with the monthly security patch. If shit doesn't break, why not upgrade all the time?

A nit to pick...
If you're using the Chrome example in earnest, you clearly fit into at least one of the following groups:
- People who use a very small and fairly unchanging list of websites
- People who do not have web development as part of their job description
- People who do not notice when things change adversely, but still work (think cosmetic/rendering changes)
- People who don't know what "flawlessly" means
- Unicorns

Why?
Every. Single. Chrome. Update. breaks something, somewhere.
Just because you haven't encountered it or haven't noticed it doesn't mean it's not a thing.

 

[Adreaver]

So a few times in my period as the business partner in charge of hiring / orchestrating the IP people in a former job, I had to be in charge of roll out and testing of a major Windows "SP" update that was the equivalent of a full OS update. W2K SP4 and XP SP2 & 3.

The IP guys were careful in testing these with all our custom software. On each occasion we had to go to the software guys for some customization to fix things that broke with the SP update.

I've been saying for years that having Windows 10 on a cadence to push the equivalent of that kind of OS update, again the essential basics of which would be in inplace OS upgrade, twice a year is just too fucking much.

Every time. Every damn time there is something. And with Windows home users completely helpless to prevent it, its getting a little old. They need to dial it back to once a year and give themselves a full 6 months of testing so that these updates are perfect every time.

I don't really care how often they push updates as long as they don't break shit. Google pushes updates to Chrome (and Chrome OS) more often flawlessly. The difference in complexity is obvious but it's more philosophical than that.

Internally, Microsoft can work on a feature update as long as they want. They should focus on extensive regression testing against as many targets as they can and spend time divorcing that update from other bits of code (refactor!). Hell, they can "shadow install" updates on active Windows install in the wild just to see if that process craps out (don't give it actual authority!).

And at the end of the day, when the features work feel free to ship twice per year. Or hell, with the monthly security patch. If shit doesn't break, why not upgrade all the time?

A nit to pick...
If you're using the Chrome example in earnest, you clearly fit into at least one of the following groups:
- People who use a very small and fairly unchanging list of websites
- People who do not have web development as part of their job description
- People who do not notice when things change adversely, but still work (think cosmetic/rendering changes)
- People who don't know what "flawlessly" means
- Unicorns

Why?
Every. Single. Chrome. Update. breaks something, somewhere.
Just because you haven't encountered it or haven't noticed it doesn't mean it's not a thing.

To be fair, the things that break typically don't impact the experience of the vast majority of end users, and they are often fixed in the next update (which breaks something else, which is also unlikely to affect the vast majority of end users).

Except for that time that a Chrome update broke CSS entirely and I was browsing the web like it was 1995.

 

[dodexahedron]

So a few times in my period as the business partner in charge of hiring / orchestrating the IP people in a former job, I had to be in charge of roll out and testing of a major Windows "SP" update that was the equivalent of a full OS update. W2K SP4 and XP SP2 & 3.

The IP guys were careful in testing these with all our custom software. On each occasion we had to go to the software guys for some customization to fix things that broke with the SP update.

I've been saying for years that having Windows 10 on a cadence to push the equivalent of that kind of OS update, again the essential basics of which would be in inplace OS upgrade, twice a year is just too fucking much.

Every time. Every damn time there is something. And with Windows home users completely helpless to prevent it, its getting a little old. They need to dial it back to once a year and give themselves a full 6 months of testing so that these updates are perfect every time.

I don't really care how often they push updates as long as they don't break shit. Google pushes updates to Chrome (and Chrome OS) more often flawlessly. The difference in complexity is obvious but it's more philosophical than that.

Internally, Microsoft can work on a feature update as long as they want. They should focus on extensive regression testing against as many targets as they can and spend time divorcing that update from other bits of code (refactor!). Hell, they can "shadow install" updates on active Windows install in the wild just to see if that process craps out (don't give it actual authority!).

And at the end of the day, when the features work feel free to ship twice per year. Or hell, with the monthly security patch. If shit doesn't break, why not upgrade all the time?

A nit to pick...
If you're using the Chrome example in earnest, you clearly fit into at least one of the following groups:
- People who use a very small and fairly unchanging list of websites
- People who do not have web development as part of their job description
- People who do not notice when things change adversely, but still work (think cosmetic/rendering changes)
- People who don't know what "flawlessly" means
- Unicorns

Why?
Every. Single. Chrome. Update. breaks something, somewhere.
Just because you haven't encountered it or haven't noticed it doesn't mean it's not a thing.

To be fair, the things that break typically don't impact the experience of the vast majority of end users, and they are often fixed in the next update (which breaks something else, which is also unlikely to affect the vast majority of end users).

Except for that time that a Chrome update broke CSS entirely and I was browsing the web like it was 1995.

Which is kind of the point of most people, here...
This is a non-issue, because it's getting caught before the vast majority of users will have the chance to encounter it, which means everything is working as planned.

This is sorta like crying that an early release game on steam is buggy before its final release.
Well... Duh...

 

[Wickwick]

So a few times in my period as the business partner in charge of hiring / orchestrating the IP people in a former job, I had to be in charge of roll out and testing of a major Windows "SP" update that was the equivalent of a full OS update. W2K SP4 and XP SP2 & 3.

The IP guys were careful in testing these with all our custom software. On each occasion we had to go to the software guys for some customization to fix things that broke with the SP update.

I've been saying for years that having Windows 10 on a cadence to push the equivalent of that kind of OS update, again the essential basics of which would be in inplace OS upgrade, twice a year is just too fucking much.

Every time. Every damn time there is something. And with Windows home users completely helpless to prevent it, its getting a little old. They need to dial it back to once a year and give themselves a full 6 months of testing so that these updates are perfect every time.

I don't really care how often they push updates as long as they don't break shit. Google pushes updates to Chrome (and Chrome OS) more often flawlessly. The difference in complexity is obvious but it's more philosophical than that.

Internally, Microsoft can work on a feature update as long as they want. They should focus on extensive regression testing against as many targets as they can and spend time divorcing that update from other bits of code (refactor!). Hell, they can "shadow install" updates on active Windows install in the wild just to see if that process craps out (don't give it actual authority!).

And at the end of the day, when the features work feel free to ship twice per year. Or hell, with the monthly security patch. If shit doesn't break, why not upgrade all the time?

A nit to pick...
If you're using the Chrome example in earnest, you clearly fit into at least one of the following groups:
- People who use a very small and fairly unchanging list of websites
- People who do not have web development as part of their job description
- People who do not notice when things change adversely, but still work (think cosmetic/rendering changes)
- People who don't know what "flawlessly" means
- Unicorns

Why?
Every. Single. Chrome. Update. breaks something, somewhere.
Just because you haven't encountered it or haven't noticed it doesn't mean it's not a thing.

To be fair, the things that break typically don't impact the experience of the vast majority of end users, and they are often fixed in the next update (which breaks something else, which is also unlikely to affect the vast majority of end users).

Except for that time that a Chrome update broke CSS entirely and I was browsing the web like it was 1995.

Which is kind of the point of most people, here...
This is a non-issue, because it's getting caught before the vast majority of users will have the chance to encounter it, which means everything is working as planned.

This is sorta like crying that an early release game on steam is buggy before its final release.
Well... Duh...

Except by the time it was in a canary build, it's likely Google would have already caught a bug like this. This build has been through the Microsoft equivalent of a canary and test build and it's headed to a preview ring. That's several stages of development further.

 

[dodexahedron]

So a few times in my period as the business partner in charge of hiring / orchestrating the IP people in a former job, I had to be in charge of roll out and testing of a major Windows "SP" update that was the equivalent of a full OS update. W2K SP4 and XP SP2 & 3.

The IP guys were careful in testing these with all our custom software. On each occasion we had to go to the software guys for some customization to fix things that broke with the SP update.

I've been saying for years that having Windows 10 on a cadence to push the equivalent of that kind of OS update, again the essential basics of which would be in inplace OS upgrade, twice a year is just too fucking much.

Every time. Every damn time there is something. And with Windows home users completely helpless to prevent it, its getting a little old. They need to dial it back to once a year and give themselves a full 6 months of testing so that these updates are perfect every time.

I don't really care how often they push updates as long as they don't break shit. Google pushes updates to Chrome (and Chrome OS) more often flawlessly. The difference in complexity is obvious but it's more philosophical than that.

Internally, Microsoft can work on a feature update as long as they want. They should focus on extensive regression testing against as many targets as they can and spend time divorcing that update from other bits of code (refactor!). Hell, they can "shadow install" updates on active Windows install in the wild just to see if that process craps out (don't give it actual authority!).

And at the end of the day, when the features work feel free to ship twice per year. Or hell, with the monthly security patch. If shit doesn't break, why not upgrade all the time?

A nit to pick...
If you're using the Chrome example in earnest, you clearly fit into at least one of the following groups:
- People who use a very small and fairly unchanging list of websites
- People who do not have web development as part of their job description
- People who do not notice when things change adversely, but still work (think cosmetic/rendering changes)
- People who don't know what "flawlessly" means
- Unicorns

Why?
Every. Single. Chrome. Update. breaks something, somewhere.
Just because you haven't encountered it or haven't noticed it doesn't mean it's not a thing.

To be fair, the things that break typically don't impact the experience of the vast majority of end users, and they are often fixed in the next update (which breaks something else, which is also unlikely to affect the vast majority of end users).

Except for that time that a Chrome update broke CSS entirely and I was browsing the web like it was 1995.

Which is kind of the point of most people, here...
This is a non-issue, because it's getting caught before the vast majority of users will have the chance to encounter it, which means everything is working as planned.

This is sorta like crying that an early release game on steam is buggy before its final release.
Well... Duh...

Except by the time it was in a canary build, it's likely Google would have already caught a bug like this. This build has been through the Microsoft equivalent of a canary and test build and it's headed to a preview ring. That's several stages of development further.

Huh?
How can you make that assertion?
By the first quote's own admission, this is a completely different ballgame, with regards to complexity of the software.
And no - Google have made it to production with said issues. That's objectively worse than this.

Let's not pretend Google are magic unicorns. They have enough apologists as it is...

But seriously.
If you are in the insider program, you are, by definition, not a normal user; you voluntarily are accepting that you are testing the software; you accept that you may have problems, up to and including loss of data or hardware damage; and you have no legitimate expectation otherwise, outside of active malice or gross negligence on the part of Microsoft, for which this qualifies as neither.
It's all there in the EULA.
People read those, right?

 

[Jognt]

So what you're saying is...I can just delay the update indefinitely by plugging in a USB drive?

It’s weird. Your witty comment on how to regain control over the updates gets “all the upvotes”, yet posts about Win7 users that don’t want auto-updates get “all the downvotes”.

In the end, I’m glad we all agree on one thing: MS QA is horrid.

The difference is security updates. I'm still accepting those, I just don't want the "feature" updates, because every freaking one breaks something and wastes my time trying to figure out how to fix it. And all I get in return is a feature I never wanted, that sometimes replaces a perfectly good feature with a worse one.

Example anecdote: last one screwed up my audio config (my microphone just stopped working completely...turned out for some reason all applications were suddenly forbidden from accessing it in security settings)...and two of my friends also had audio problems on that update. But each one of us had a different audio problem. And AFAIK we all have simple setups, just stereo speakers and a headset (and generally just switching between them depending on the situation), so it's not like we're some weird edge-case.

But Windows 7 doesn't really have much in the way of feature updates, it's mostly bug fixes and security updates. Avoiding those is a different story.

I meant Win7 users that avoid win10 due to the forced updates. I can’t imagine anyone ignoring security updates regardless of the platform.

I assumed you meant Windows 7 users that disable Windows Update because they don't want any automatic updates (because I have certainly seen those around in the comments section too).

But that's literally what staying on 7 gets you in the long-term though (well, not that long at this point):

Microsoft[/url]":3ift9kuj]After January 14, 2020, Microsoft will no longer provide security updates or support for PCs running Windows 7.

I hope Win10 (and MS) have matured enough by that time. I’m not planning on running Win7 without security updates. Win10 is the first one I am really not looking forward to. And I believed in Vista from the start.

 

[gnz]

So, my old trusty Surface 3 is free from updates as long as I keep the SD card plugged in? Neat!

 

[panton41]

Quote: "The reason for blocking the update is that it appears to be prone to shuffling the drive letters assigned to USB and SD storage devices. In other words, while your USB drive might show up as "" now, it could end up getting renamed to "E:" after upgrading to 1903. Fortunately, there is a straightforward workaround: unplug the drives and remove the memory card ..."

I have a better workaround -- eliminate drive letters, which date back to DOS and at the very least represent an embarrassment in modern times. The presence of drive letters in Windows 10 only tells us how old the oldest code in Windows is. Drive letters are to a modern operating system what a disfiguring congenital birthmark would be in a person.

No other modern operating system recognizes, or relies on, drive letters. Before anyone mentions OS/2, I emphasize that I specified "modern operating system".

I can't tell you how many times I've heard from Windows 10 end users who cannot reliably back up their systems because some external storage devices are automatically assigned one drive letter, some another, with no predictable pattern or reliability. What Windows won't do is assign or accept a *user-defined name* for a storage device, which would solve this issue once and for all.

This is how Linux/Unix deals with this issue. Just saying.

It amazes me how *nix zealots pretend drive letters are such a major problem but can literally give zero concrete reasons why it's a problem other than it's not how *nix does it.

Does "Windows 10 May 2019 update blocked for anyone using USB or SD storage." sound familiar? (It's the title of this article which you are posting to.)

And? The drive letter doesn't magically make this happen. It's the logical assignment, which is also a "thing" that breaks in *nix during major updates.

First of all, Skippy, the codebase for *nix defacto dates back to 1969, so let's not pretend it's all that modern. How *nix handles everything as a file isn't all that special in the scheme of things and in some cases it's a huge detriment and there's kludges in the Linux kernel to get around that that make Microsoft's userland kludges for legacy software look pedestrian.

I'd love to review an example of what you consider to be an extra-pedestrian Linux kludge.

Please provide a link to the specific source code.

You first. You know that literally no one can actually vet the Linux kernel, and an entire distro built on top of that, for even major security flaws much less stuff like this. And that's despite every line of source code being available. The earlier quote of about 100-million lines of code in Windows is probably about right, if not low, for your average Linux distro. You have to trust the company doing it isn't selling you out to a three-letter agency, kind of like with Windows.

Having said that, the main place I've heard the problem cropping up is in direct memory access to things like graphics drivers where treating various things as a file simply doesn't work.

Once drive letters are set on permanently and semi-permanently connect drives Windows assigns the same ones every reboot unless something drastic happens like, you know, functionally reinstalling the operating system.

Or you install the May 2019 Windows patch?
Or you update a device driver, and the system bus topology ordering changes?

Unix originated on PDP mainframes and became popular on Sun and HP-PA hardware, which tended to use OpenFirmware rather than a PC BIOS and almost always exhibited stable system bus topology ordering. (To be fair, EFI in modern PCs could actually do better, but legacy compatibility with the BIOS world makes that complex.)

With x86-based hardware, flavors of Unix/Linux have added either disk-partition based drive labelling, or a UUID-to-device ordering held on the root filesystem, or both. This allows the devices to be enumerated consistently so that /etc/mounts doesn't break.

Um, I have no clue what point you're trying to make here. I see bragging about technology that was cutting edge when Tricky Dick was in office and then Dunning-Kruger taking hold about modern hardware.

Modern hardware logically exposes stuff like serial numbers, which is how any OS uniquely identifies what's attached. This has been true since the mid-1990s and Intel exposing it on CPUs was a huge scandal back then, but these days every piece of attached hardware does it.

The fact this problem was caught during beta testing should be enough to say it's not a major concern. Shit happens and some of the ugliest fuck-your-system-up-the-exhaust-port-with-a-corn-cob shit I've had happen was while beta testing a Linux distro.

 

[cwsars]

Quote: "The reason for blocking the update is that it appears to be prone to shuffling the drive letters assigned to USB and SD storage devices. In other words, while your USB drive might show up as "" now, it could end up getting renamed to "E:" after upgrading to 1903. Fortunately, there is a straightforward workaround: unplug the drives and remove the memory card ..."

I have a better workaround -- eliminate drive letters, which date back to DOS and at the very least represent an embarrassment in modern times. The presence of drive letters in Windows 10 only tells us how old the oldest code in Windows is. Drive letters are to a modern operating system what a disfiguring congenital birthmark would be in a person.

No other modern operating system recognizes, or relies on, drive letters. Before anyone mentions OS/2, I emphasize that I specified "modern operating system".

I can't tell you how many times I've heard from Windows 10 end users who cannot reliably back up their systems because some external storage devices are automatically assigned one drive letter, some another, with no predictable pattern or reliability. What Windows won't do is assign or accept a *user-defined name* for a storage device, which would solve this issue once and for all.

This is how Linux/Unix deals with this issue. Just saying.

It amazes me how *nix zealots pretend drive letters are such a major problem but can literally give zero concrete reasons why it's a problem other than it's not how *nix does it.

Does "Windows 10 May 2019 update blocked for anyone using USB or SD storage." sound familiar? (It's the title of this article which you are posting to.)

And? The drive letter doesn't magically make this happen. It's the logical assignment, which is also a "thing" that breaks in *nix during major updates.

Should problems with logical assignment be a "thing"?
Should those problems blacklist OS and/or security updates?

My answers are no and no, respectively.

I previously mentioned two different mechanisms by which persistent logical assignment is handled in Unix. Please point me to patch notes from a 2019 flavor of Unix where having removable storage in use will result in the update/patch not applying?

First of all, Skippy, the codebase for *nix defacto dates back to 1969, so let's not pretend it's all that modern. How *nix handles everything as a file isn't all that special in the scheme of things and in some cases it's a huge detriment and there's kludges in the Linux kernel to get around that that make Microsoft's userland kludges for legacy software look pedestrian.

I'd love to review an example of what you consider to be an extra-pedestrian Linux kludge.

Please provide a link to the specific source code.

You first.

You're walking back your claim, I see.

You know that literally no one can actually vet the Linux kernel, and an entire distro built on top of that, for even major security flaws much less stuff like this. And that's despite every line of source code being available.

I asked for a single example.

Stating that "literally no can" review the Linux kernel is not even a plausible excuse. If you actually had an example in mind, kernel.org is a click away.

The fact this problem was caught during beta testing should be enough to say it's not a major concern. Shit happens and some of the ugliest fuck-your-system-up-the-exhaust-port-with-a-corn-cob shit I've had happen was while beta testing a Linux distro.

The fact that this problem reached beta testing has been described as "frankly remarkable" by one local author. Not having a system or security update apply should be a major concern.

Look, Windows is a platform and a tool. I'm less interested in throwing stones than I am in setting reasonable expectations and finding sane workarounds for problems.

But I've had to fight with USB settings recently because Windows 10 decided that my external backup drive should no longer be mounted using caching, so backup decided it wasn't reliable enough to keep running backups against. It's fixed again, but it never should have been changed to begin with.

smartctl -a /dev/sdc tells me the drive is a "WDC WD40NMZW-11GX6S1".

With apologies to Monty Python, it would make me sad if Windows decides that sdc is now sdd, and sde would be right out. sdc is the drive letter that WDC via USB thou shalt enumerate, and the drive letter of the counting shall be three. No, C. No, not C:, that's /dev/sda. /dev/sdc is G:, and any alteration will be deemed naughty in My sight.

 

[panton41]

Quote: "The reason for blocking the update is that it appears to be prone to shuffling the drive letters assigned to USB and SD storage devices. In other words, while your USB drive might show up as "" now, it could end up getting renamed to "E:" after upgrading to 1903. Fortunately, there is a straightforward workaround: unplug the drives and remove the memory card ..."

I have a better workaround -- eliminate drive letters, which date back to DOS and at the very least represent an embarrassment in modern times. The presence of drive letters in Windows 10 only tells us how old the oldest code in Windows is. Drive letters are to a modern operating system what a disfiguring congenital birthmark would be in a person.

No other modern operating system recognizes, or relies on, drive letters. Before anyone mentions OS/2, I emphasize that I specified "modern operating system".

I can't tell you how many times I've heard from Windows 10 end users who cannot reliably back up their systems because some external storage devices are automatically assigned one drive letter, some another, with no predictable pattern or reliability. What Windows won't do is assign or accept a *user-defined name* for a storage device, which would solve this issue once and for all.

This is how Linux/Unix deals with this issue. Just saying.

It amazes me how *nix zealots pretend drive letters are such a major problem but can literally give zero concrete reasons why it's a problem other than it's not how *nix does it.

Does "Windows 10 May 2019 update blocked for anyone using USB or SD storage." sound familiar? (It's the title of this article which you are posting to.)

And? The drive letter doesn't magically make this happen. It's the logical assignment, which is also a "thing" that breaks in *nix during major updates.

Should problems with logical assignment be a "thing"?
Should those problems blacklist OS and/or security updates?

My answers are no and no, respectively.

I previously mentioned two different mechanisms by which persistent logical assignment is handled in Unix. Please point me to patch notes from a 2019 flavor of Unix where having removable storage in use will result in the update/patch not applying?

First of all, Skippy, the codebase for *nix defacto dates back to 1969, so let's not pretend it's all that modern. How *nix handles everything as a file isn't all that special in the scheme of things and in some cases it's a huge detriment and there's kludges in the Linux kernel to get around that that make Microsoft's userland kludges for legacy software look pedestrian.

I'd love to review an example of what you consider to be an extra-pedestrian Linux kludge.

Please provide a link to the specific source code.

You first.

You're walking back your claim, I see.

You know that literally no one can actually vet the Linux kernel, and an entire distro built on top of that, for even major security flaws much less stuff like this. And that's despite every line of source code being available.

I asked for a single example.

Stating that "literally no can" review the Linux kernel is not even a plausible excuse. If you actually had an example in mind, kernel.org is a click away.

The fact this problem was caught during beta testing should be enough to say it's not a major concern. Shit happens and some of the ugliest fuck-your-system-up-the-exhaust-port-with-a-corn-cob shit I've had happen was while beta testing a Linux distro.

The fact that this problem reached beta testing has been described as "frankly remarkable" by one local author. Not having a system or security update apply should be a major concern.

Look, Windows is a platform and a tool. I'm less interested in throwing stones than I am in setting reasonable expectations and finding sane workarounds for problems.

But I've had to fight with USB settings recently because Windows 10 decided that my external backup drive should no longer be mounted using caching, so backup decided it wasn't reliable enough to keep running backups against. It's fixed again, but it never should have been changed to begin with.

smartctl -a /dev/sdc tells me the drive is a "WDC WD40NMZW-11GX6S1".

With apologies to Monty Python, it would make me sad if Windows decides that sdc is now sdd, and sde would be right out. sdc is the drive letter that WDC via USB thou shalt enumerate, and the drive letter of the counting shall be three. No, C. No, not C:, that's /dev/sda. /dev/sdc is G:, and any alteration will be deemed naughty in My sight.

Frankly, you're being an asshole right now and have move the goalpost to the next metro area over. I'm done.

I don't give a shit about Linux, and haven't used it for myself for more than testing in close to a decade for a reason. I'm not going to have a religious argument with a zealot with an ax to grind.

To quote Shakespeare, "You may as well go stand upon the beach; And bid the main flood bate his usual height; You may as well use question with the wolf; Why he hath made the ewe bleat for the lamb..." than get a Linux zealot to admit it's anything but god's gift to computing.

 

[cwsars]

Frankly, you're being an asshole right now and have move the goalpost to the next metro area over. I'm done.

After being asked to provide an example, you've gone for the trifecta of an ad hominem attack, claiming goalposts have been moved, and that you're out of here.

See you around, space cowboy...

I don't give a shit about Linux, and haven't used it for myself for more than testing in close to a decade for a reason. I'm not going to have a religious argument with a zealot with an ax to grind.

Projection much?

 

[int19]

Ok question, are software developers becoming more inept? How can they not simply write it so it doesn't shuffle the drive letters around? That does not sound like an insurmountable issue.

It's an operating system, I don't think updates are "simply". Not saying they couldn't ,but I suspect there is some legitimate complexity here.

Complexity which is exacerbated by the continual addition of features. Features that don't necessarily improve function.

 

[int19]

Ok question, are software developers becoming more inept? How can they not simply write it so it doesn't shuffle the drive letters around? That does not sound like an insurmountable issue.

Windows is gigantic, with something like 100mm lines of code in all. At that scale, even seemingly inconsequential changes can have some rather chaotic results.

What the heck is 'mm' as a label for number of something? 1,000? 1,000,000? The customary (and SI) labels would be 'k' and 'M.'

Not all domains use SI suffixes. In business and finance, M was traditionally used to denote "thousands" (from the Roman Numeral M), and so millions became "MM". It is still used quite widely in many different industries, particularly in financial contexts.

 

[int19]

As a reminder, folks, always create an empty text file with the filename of "X"-drive in the root folder of any drive you plug in, with X being the drive letter in Windows in your system; that will allow you to quickly map the drive back to the correct location after an update (or hardware repair/replacement/shuffling)

Advanced.

If only there was some way the electronic computing device could automatically read such files and map the drives to the location they previously existed at... But alas, such a notion is pure fancy!

 

[int19]

The more esoteric the bugs that block an update the more concerned I am for the future. Apparently this update might scramble USB drive letters, but not hard drives? There are just too many interconnections between the bits of code in Windows that have unforeseeable consequences as changes are applied.

Perhaps instead of adding new features each build, Microsoft should really be focusing on reducing the inter-connections wherever possible or on simplifying the codebase as much as possible. I realize Windows does a lot so a minimum level of complexity is required. But I suspect we're not near that limit.

Microsoft was trying to do just that - clean Windows up, reduce interdependencies, simplify the codebase, etc. - with Project Longhorn, which was ultimately scrapped after several years of development. They ended up cobbling Vista together out of the leftovers of Longhorn and XP.

That was 15+ years ago, to be fair, but I'm not sure Microsoft possesses the ability to re-write Windows from the ground up. I think it has become a larger beast than its creators at this point.

Source: https://medium.com/@benbob/what-really-happened-with-vista-an-insiders-retrospective-f713ee77c239

So ... let's add more features to it!

 

[int19]

Not sure I understand the last paragraph, since it WAS caught in testing - with us RP people, the last line of defense. You can crow all you want about how it 'should have' been spotted sooner and fixed, but really, who cares? The vast, VAST majority of Windows 10 users are not in the any of the testing rings, so as long as it's fixed by general release, it doesn't matter.

Now if they STILL dont have this sorted out by the time this update goes live, then you can complain, and rightly so (they are giving us RP basically a month of time - which should be long enough to spot many thing and fix them too).

If it still isn't fix by prime time, then I dont think the problem is really testing/QA as you at Ars generally claim, I have to call into question how the Windows team is currently split up or rather, how they were organized at the last reorg. After all, we talking a "we know about it early enough" bug, and yet there is no news on when the fix will happen (as far as I can see). Perhaps instead its about how they handle the builds and when they go out. How many people back at MS are working on this build VS some future build?


EDIT - "Add another one to the 'how did this get through testing' pile" It didn't, it's still being tested.

Regardless of whether they identified the issue in time or not, the bigger question in my mind is what seemingly unrelated change was made in the codebase in the first place to cause this regression to occur?

I mean, if I take my car in to have the oil changed and the mechanic calls me up to tell me the wheels fell off, I might have some questions as to exactly how that came to be the case.

 

[Wickwick]

Ok question, are software developers becoming more inept? How can they not simply write it so it doesn't shuffle the drive letters around? That does not sound like an insurmountable issue.

Windows is gigantic, with something like 100mm lines of code in all. At that scale, even seemingly inconsequential changes can have some rather chaotic results.

What the heck is 'mm' as a label for number of something? 1,000? 1,000,000? The customary (and SI) labels would be 'k' and 'M.'

Not all domains use SI suffixes. In business and finance, M was traditionally used to denote "thousands" (from the Roman Numeral M), and so millions became "MM". It is still used quite widely in many different industries, particularly in financial contexts.

Capital 'MM' I would have guessed was millions. I think even the financials industries are moving away from 'M' to denote thousands and have moved (or are moving) to 'kilo-' or 'k.'

But when discussing the total number of lines of code, I don't think most people would assume 'mm' was a million. That's the advantage of the SI system. It's becoming the norm for most everything. Almost everyone would have assumed 'M' meant millions and when in doubt, 10^6 works every time.

 

[agony]

i'm on insider betas with real HW, not VM. the problem Never happened to me.

 

[acmegamer]

I keep a microSD card in my Surface 3 at nearly all times. If I wasn't following tech news and/or wasn't diligent on checking for updates, I could conceivably never learn of this issue and be stuck on 1803 for the rest of my device's life.

I'm flabbergasted that this is a thing.

Out of curiosity, what makes you think this is a permanent situation that will persist for the "rest of your device's life"?

Microsoft places temporary blocks on specific hardware/software configurations for every feature update. It's part of the process of ensuring a smooth rollout. Eventually, the issues are addressed and the blocks are lifted.

Maybe like some of us he's going off of Microsoft's success of updating 1803 to 1809? I know I'm not the only one who watched that failed install repeatedly and still can't get one of my systems to update/upgrade to it.

 

[jandrese]

From the MS support article:

"The drive reassignment is not limited to removable drives. Internal hard drives can also be affected."

Yikes... that's definitely a major nuisance for people, like me, who have their OS on an SSD, their files on a HDD, and map their documents/pictures/etc. folder to the HDD.

The typical OS C data \ setup wouldn't have an issue since it's not going to forget the OS drive letter.

My setup, OTOH...

May I introduce you to the concept of a NAS?

 

[cbreak]

I don't see the problem with drive letters changing. It's not like they're guaranteed to be constant, or even give any expectation to remain constant. After all, if you plug in several USB sticks, they can't all get the same letter. And that letter is likely determined by the order of plugging them in.

Just use the name or serial number of the drive, or the partition / partition table UUID instead if something constant is needed.

 

[lewax00]

I don't see the problem with drive letters changing. It's not like they're guaranteed to be constant, or even give any expectation to remain constant. After all, if you plug in several USB sticks, they can't all get the same letter. And that letter is likely determined by the order of plugging them in.

Just use the name or serial number of the drive, or the partition / partition table UUID instead if something constant is needed.

Agree with removable drives, but:

From the MS support article:

"The drive reassignment is not limited to removable drives. Internal hard drives can also be affected."

That's potentially a problem.

It's also possible that some people are using external USB drives as more permanent drives instead of as removable drives, and would encounter the same problems as internal drives would have (shortcuts not working, programs not finding files where they're expected, etc.).

 

[Wickwick]

I don't see the problem with drive letters changing. It's not like they're guaranteed to be constant, or even give any expectation to remain constant. After all, if you plug in several USB sticks, they can't all get the same letter. And that letter is likely determined by the order of plugging them in.

Just use the name or serial number of the drive, or the partition / partition table UUID instead if something constant is needed.

I want the contents of a drive to be accessible when I clone the partitions somewhere else. You cannot tie identification to hardware. I'm good having it tied to a partition ID.

 

[cbreak]

I don't see the problem with drive letters changing. It's not like they're guaranteed to be constant, or even give any expectation to remain constant. After all, if you plug in several USB sticks, they can't all get the same letter. And that letter is likely determined by the order of plugging them in.

Just use the name or serial number of the drive, or the partition / partition table UUID instead if something constant is needed.

Agree with removable drives, but:

From the MS support article:

"The drive reassignment is not limited to removable drives. Internal hard drives can also be affected."

That's potentially a problem.

It's also possible that some people are using external USB drives as more permanent drives instead of as removable drives, and would encounter the same problems as internal drives would have (shortcuts not working, programs not finding files where they're expected, etc.).

/dev/ files aren't guaranteed to remain consistent across reboots or even during operation for Mac OS X or Linux either. Not even of my internal SSDs or HDDs. (I think their order changes based on the time they happen to take to reply to the kernel when it enumerates devices).

It's no big deal in general operation, since no one cares about those outside admin tasks. If you want something more consistent, you'd use a disk/by-id, disk/by-serial or similar alternative to get a consistent device (I wrote https://github.com/cbreak-black/InvariantDisks to fake the linux mechanism on Mac OS X). And mount the devices where ever you want based on id, serial or similar based on this.

People seem to abuse drive letters as something it never promised to be: An invariant identifier.

 

[cbreak]

I don't see the problem with drive letters changing. It's not like they're guaranteed to be constant, or even give any expectation to remain constant. After all, if you plug in several USB sticks, they can't all get the same letter. And that letter is likely determined by the order of plugging them in.

Just use the name or serial number of the drive, or the partition / partition table UUID instead if something constant is needed.

I want the contents of a drive to be accessible when I clone the partitions somewhere else. You cannot tie identification to hardware. I'm good having it tied to a partition ID.

I can tie it to what ever I want . Physical bus topology is nice, then you can identify replaced drives as the-same. File System or Partition UUID is nice for the reason you mentioned, and also being somewhat portable. Drive serial is guaranteed unique. They all have their pros and cons, but unlike drive letters, they are actually meant to be invariant.

 

[lewax00]

I don't see the problem with drive letters changing. It's not like they're guaranteed to be constant, or even give any expectation to remain constant. After all, if you plug in several USB sticks, they can't all get the same letter. And that letter is likely determined by the order of plugging them in.

Just use the name or serial number of the drive, or the partition / partition table UUID instead if something constant is needed.

Agree with removable drives, but:

From the MS support article:

"The drive reassignment is not limited to removable drives. Internal hard drives can also be affected."

That's potentially a problem.

It's also possible that some people are using external USB drives as more permanent drives instead of as removable drives, and would encounter the same problems as internal drives would have (shortcuts not working, programs not finding files where they're expected, etc.).

/dev/ files aren't guaranteed to remain consistent across reboots or even during operation for Mac OS X or Linux either. Not even of my internal SSDs or HDDs. (I think their order changes based on the time they happen to take to reply to the kernel when it enumerates devices).

It's no big deal in general operation, since no one cares about those outside admin tasks. If you want something more consistent, you'd use a disk/by-id, disk/by-serial or similar alternative to get a consistent device (I wrote https://github.com/cbreak-black/InvariantDisks to fake the linux mechanism on Mac OS X). And mount the devices where ever you want based on id, serial or similar based on this.

People seem to abuse drive letters as something it never promised to be: An invariant identifier.

You wouldn't generally access a drive via it's /dev/ entry in Linux anyways, you'd go to whatever directory it's mounted to (especially if you actually want to use the filesystem on it...).

Unfortunately Windows basically uses drive letters the same way as you might use the mount path in Linux. Plenty of parts of Windows itself expect that drive letters will not change, so I'm not sure I buy that they weren't meant to be invariant, at least in some cases (e.g. change your C: drive to anything else and see what happens).

 

[cbreak]

I don't see the problem with drive letters changing. It's not like they're guaranteed to be constant, or even give any expectation to remain constant. After all, if you plug in several USB sticks, they can't all get the same letter. And that letter is likely determined by the order of plugging them in.

Just use the name or serial number of the drive, or the partition / partition table UUID instead if something constant is needed.

Agree with removable drives, but:

From the MS support article:

"The drive reassignment is not limited to removable drives. Internal hard drives can also be affected."

That's potentially a problem.

It's also possible that some people are using external USB drives as more permanent drives instead of as removable drives, and would encounter the same problems as internal drives would have (shortcuts not working, programs not finding files where they're expected, etc.).

/dev/ files aren't guaranteed to remain consistent across reboots or even during operation for Mac OS X or Linux either. Not even of my internal SSDs or HDDs. (I think their order changes based on the time they happen to take to reply to the kernel when it enumerates devices).

It's no big deal in general operation, since no one cares about those outside admin tasks. If you want something more consistent, you'd use a disk/by-id, disk/by-serial or similar alternative to get a consistent device (I wrote https://github.com/cbreak-black/InvariantDisks to fake the linux mechanism on Mac OS X). And mount the devices where ever you want based on id, serial or similar based on this.

People seem to abuse drive letters as something it never promised to be: An invariant identifier.

You wouldn't generally access a drive via it's /dev/ entry in Linux anyways, you'd go to whatever directory it's mounted to (especially if you actually want to use the filesystem on it...).

Unfortunately Windows basically uses drive letters the same way as you might use the mount path in Linux. Plenty of parts of Windows itself expect that drive letters will not change, so I'm not sure I buy that they weren't meant to be invariant, at least in some cases (e.g. change your C: drive to anything else and see what happens).

Every time you boot from an other partition, C changes to something else. It's the way windows is designed to work. It's explicitly NOT invariant. My limited observation of that platform indicate that apart from drive letters I assign myself (for smb shares), they are allocated on a first come, first serve basis, starting with C, for some reason, which always happens to be the boot partition that is booted right now.

 

[lewax00]

I don't see the problem with drive letters changing. It's not like they're guaranteed to be constant, or even give any expectation to remain constant. After all, if you plug in several USB sticks, they can't all get the same letter. And that letter is likely determined by the order of plugging them in.

Just use the name or serial number of the drive, or the partition / partition table UUID instead if something constant is needed.

Agree with removable drives, but:

From the MS support article:

"The drive reassignment is not limited to removable drives. Internal hard drives can also be affected."

That's potentially a problem.

It's also possible that some people are using external USB drives as more permanent drives instead of as removable drives, and would encounter the same problems as internal drives would have (shortcuts not working, programs not finding files where they're expected, etc.).

/dev/ files aren't guaranteed to remain consistent across reboots or even during operation for Mac OS X or Linux either. Not even of my internal SSDs or HDDs. (I think their order changes based on the time they happen to take to reply to the kernel when it enumerates devices).

It's no big deal in general operation, since no one cares about those outside admin tasks. If you want something more consistent, you'd use a disk/by-id, disk/by-serial or similar alternative to get a consistent device (I wrote https://github.com/cbreak-black/InvariantDisks to fake the linux mechanism on Mac OS X). And mount the devices where ever you want based on id, serial or similar based on this.

People seem to abuse drive letters as something it never promised to be: An invariant identifier.

You wouldn't generally access a drive via it's /dev/ entry in Linux anyways, you'd go to whatever directory it's mounted to (especially if you actually want to use the filesystem on it...).

Unfortunately Windows basically uses drive letters the same way as you might use the mount path in Linux. Plenty of parts of Windows itself expect that drive letters will not change, so I'm not sure I buy that they weren't meant to be invariant, at least in some cases (e.g. change your C: drive to anything else and see what happens).

Every time you boot from an other partition, C changes to something else. It's the way windows is designed to work. It's explicitly NOT invariant. My limited observation of that platform indicate that apart from drive letters I assign myself (for smb shares), they are allocated on a first come, first serve basis, starting with C, for some reason, which always happens to be the boot partition that is booted right now.

Huh? If you're booting from another partition, you're booting into a different operating system instance. Of course it would have a different mapping, my drives also map differently if I boot into Linux instead of Windows on a dual boot system, but that's not really relevant to anything.