Dev.SN ♥ developers
Sections
Dev.SN
from the its-my-way-or-the-highway-said-the-Borg dept.
An Anonymous Coward belatedly writes:
"Sandisk changed the configuration, beginning in 2012, for all USB drives they make so that in future external USB devices will be seen as physical hard drives. This has been done to meet requirements set by Microsoft for Windows 8 which states that all USB devices must be configured to be recognised as fixed drives (nb. this is possibly related to Windows-to-Go). This has caused havoc for many users as Sandisk drives can no longer be used with Windows Recovery or any program that will only write to USB External devices. Sandisk deleted the support page that described why Sandisk USB drives are now configured as fixed drives, although the blog author includes it in his blog.
Beware any USB pen drive which states it is "Windows 8 certified". The device will not be detectable as an external drive in Windows 8. The HP Recovery Disks page says to avoid any Windows-8-certified USB devices."
One comment on the blog suggests that Sandisk might have reverted to more conventional practices for subsequent USB devices.
(Score: 5, Interesting) by Marand on Monday March 03 2014, @03:36AM
You jest, but it still showed as /dev/sdb for him, too, and he said it still worked as expected except for buggering up his home-brew install script.
How does this actually affect Linux users? I'm guessing helpers like the one KDE* uses for popping up device notifications and auto-mounting on USB stick inserts would be affected, but what else? Nothing else is coming to mind.
I'm curious what sort of tools care about the removable flag, since most programs will only care about read/write access of specific locations, not what media the locations are mounted from.
Also, how much better or worse is the situation in Windows? Using HP's recovery software as an example make that very clear, since the last time I checked, the software HP provided with new laptops was fragile crap already.
--
* KDE's device notifier has an option to show non-removable devices as well as removable, so you could mitigate the annoyance there.
(Score: 5, Interesting) by Adrian Harvey on Monday March 03 2014, @04:29AM
My first guess would be that the external flag would affect write caching. Ie: an external device which might be removed at any time should have minimal or no write caching, so that the device, if removed without unmounting would be in a coherent state.
If the portable version of Windows 8 needs write caching to work, it would have been better to code an exception into the the disk driver to change the caching default for the case where the external drive is the system drive, rather than break things for all other uses.
(Score: 5, Insightful) by mmcmonster on Monday March 03 2014, @06:42AM
The problem is for avoiding simple mistakes on any OS.
ie: You want to burn an ISO onto a USB stick. The application only shows the removable drives as options so you don't overwrite /dev/sda or something stupid like that. Not possible anymore.
(Score: 0) by Anonymous Coward on Monday March 03 2014, @08:38AM
Perhaps Sandisk did not realise how many things are not possible when a USB drive no longer detects as external. Perhaps some real world testing with the OS they were certifying for would have helped..
(Score: 1) by morgauxo on Monday March 03 2014, @11:03AM
At least until if/when devices that DO register as removeable become rare I would continue to only list the "removable" ones by default. Then there could be a checkbox that allows all devices to be seen preceded by a "continue at your own risk" popup.
Also, do these devices have some sort of other identifying information? Like the USB manufacturer/device id? Maybe there can be a whitelist to make these devices show up. It's far from ideal but it's better than ingnoring the problem.
(Score: 1) by gottabeme on Tuesday March 04 2014, @02:56AM
I'm guessing that udev rules could be made to force said devices to be marked as removable to the kernel. I think there are already a lot of rules in the kernel, udev, and distros that have specific device IDs to work around issues, so maybe this wouldn't be a stretch. But keeping up with the device IDs might be impractical, or at least result in recent models not being caught.