Slashdot Mirror
Latest Windows 10 Update Has Yet Another File-Managing Issue (gizmodo.com.au)
An anonymous reader quotes Gizmodo:
When it was discovered earlier this month that the 1809 build of Windows 10 was deleting user files just because, Microsoft halted the update until the problem was fixed. Shame, then, that another not-as-bad-but-still-bad file overwriting bug has now reared its head. in 1809, overwriting files by extracting from an archive using File Explorer doesn't result in an overwrite prompt dialogue and also doesn't replace any files at all; it just fails silently. There are also some reports that it did overwrite items, but did so silently without asking.
Ars Technica speculates that there's a larger program with Microsoft's testing process: [M]any of the preview builds had a bug wherein deleting a directory that was synced to OneDrive crashed the machine. Not only was this bug integrated into the Windows code, it was allowed to ship to end users. This tells us some fundamental things about how Windows is being developed. Either tests do not exist at all for this code (and I've been told that yes, it's permitted to integrate code without tests, though I would hope this isn't the norm), or test failures are being regarded as acceptable, non-blocking issues, and developers are being allowed to integrate code that they know doesn't work properly...
Microsoft's new development process has, proportionately, a greater amount of time spent writing new features, and a reduced amount of time stabilizing and fixing those features. That would be fine if the quality of the features were higher to start with, with the testing infrastructure to support it and higher standards before new code was integrated. But the experience with Windows 10 thus far is that Microsoft hasn't developed the processes and systems needed to sustain this new approach.
Ars Technica speculates that there's a larger program with Microsoft's testing process: [M]any of the preview builds had a bug wherein deleting a directory that was synced to OneDrive crashed the machine. Not only was this bug integrated into the Windows code, it was allowed to ship to end users. This tells us some fundamental things about how Windows is being developed. Either tests do not exist at all for this code (and I've been told that yes, it's permitted to integrate code without tests, though I would hope this isn't the norm), or test failures are being regarded as acceptable, non-blocking issues, and developers are being allowed to integrate code that they know doesn't work properly...
Microsoft's new development process has, proportionately, a greater amount of time spent writing new features, and a reduced amount of time stabilizing and fixing those features. That would be fine if the quality of the features were higher to start with, with the testing infrastructure to support it and higher standards before new code was integrated. But the experience with Windows 10 thus far is that Microsoft hasn't developed the processes and systems needed to sustain this new approach.
Wow, that's Microsoft quality!
"Everybody's naked underneath" -- The Doctor
... computing. To turn PC's into locked down devices like phones. The masses are too stupid to understand what is happening and keep feeding all these companies money. Watching PC software freedom and games being literally stolen and turned into "services" because the average person on our planet is fucking chimp level intelligence is pretty fucking disgusting.
During the April update this year, I had 3 W10 installations to get through the process. None of them worked, although one in particular went spectacularly wrong and wiped out files on the system's hidden boot partition, basically resulting in the system attempting to reboot and crashing out. There was no choice left but to perform a clean installation, then let that fresh image update.
The broken process left all sorts of log and event files scattered across my SSD and I provided them to MS, who were unable to determine the cause.
The really interesting thing for me is that the image that ate itself happens to run on the same hardware as another W10 image. I have 2 licensed copies of Windows and I use a "drive bay" to swap different bootable drives in to the same hardware. So when I upgraded the "other" image on the same platform, I was surprised to see the upgrade generate a completely different set of errors.
The biggest configuration difference between these two builds is that I use one for gaming and one for office work. Although both had the latest nVidia drivers on board, the gaming build used nVidia desktop "Surround" to create a single workspace of 5760x1200, whilst the office build just treated the display space as 3 connected monitors.
The most frustrating thing is that the feedback I was getting from the triage team who helped me (they were all volunteers and they were all excellent) was that MS had been shipping code they knew to have multiple bugs and issues in it. The problem they were having in triage was that there were *so many* bugs, it was proving next to impossible to narrow down to a specific fault.
Nadella might have turned around Microsoft's economic slide into oblivion, but his governance of the technical robustness of his company's products is, sadly, non-existent. Worse for me, both of these W10 licenses were for new-build hardware; I had no older licenses that I could grandfather in, so I'm out of pocket over £400 and have 2 systems [one box] that I simply don't trust to work reliably when MS push updates. If it were a case of "free but buggy or purchased but robust", I'd take "purchased but robust" every time. What I've actually got is "purchased but buggy". The most offensive thing is: Microsoft's actions - their continued pushing of buggy code, when there are NO COMMERCIAL DRIVERS FOR DOING SO is just plain offensive.
I wish they would just stop. Produce zero new features until ALL the bugs are squashed.
There's a reason I'm writing this post whilst running Mint Linux - and it's because I'm not trusting Windows at the moment. If I don't need to go back to Windows, I won't. I have nothing but respect and admiration for the triage volunteers over there, but Microsoft the company really don't care. That stinks.
If you have to use Windows 10, use the LTSB version. No Windows Store, no Edge, no Cortana, no platform updates, security updates only with minimal telemetry.
Microsoft don't want you to know about LTSB and do their best to hide its existence, but it's really what Windows 10 Pro should have been.
For all intensive porpoises your a bunch of rediculous loosers
Who cares that your local data gets turned into mulch. It will all just be appy app apps in the cloud soon.
From the original post:
"... a bug wherein deleting a directory that was synced to OneDrive crashed the machine.
The Cloud was the problem here. One of the reasons I never use it.
Raid on the boot partition "just works", reliably no matter what, if you use mdadm --metadata=1.0 when you create it
What that does is put the raid metadata at the end of the device. Anything that isn't raid-aware (your bios) just sees a standard filesystem, and doesn't care about the other parititions or whatever else comes AFTER the filesystem. Once the kernel launches and starts mounting filesystems, it session the raid metadata and treats it as raid.
That works because the things that don't understand raid, such as your bios, only read the data, they don't write to it. Therefore there's no worries about writing the same thing to both copies. It's only written to after the raid is mounted.
If you test that out, check to see if both drives are marked as bootable in the partition table.
If both are already marked bootable, you're good to go.
If they aren't currently and you change that, making that change could change which drive ends up being called sda.
If they aren't currently both bootable and you do not mark the other one bootable, you'd need to do so if the bootable drive fails.