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.
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.
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.
I've been running Win 8.1 with classic shell and I haven't had any of these problems, probably because they haven't produced a major update since I originally installed it. Guess I'll stick with it a bit longer. (Classic shell makes 8.1 a decent OS.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
And the reason software is turning into services is because it creates perpetual revenue streams.
Actually, you got it backwards. Patches and updates have been included in the price of software from the very beginning. What we had until recently was the requirement to pay our subscription fee for the software all upfront. But from a fiscal point of view, Software was always a subscription, as long as you got your patches and updates. You just never got the bill split up into the initial payment for the software and the subsequent payment for the software assurance subscription, as you had to pay for it all at once.
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.
Quote the parent comment: Microsoft's "... insane unpredictable chaos..."
The Microsoft chaos existed 10 years ago, but yes, the chaos is worse now. See this Scientific American article: Microsoft Vista voted tech world's top "Fiasco" (Feb. 26, 2009)
It's amazing that a company can be so badly managed that there is an article about it in Scientific American magazine.
A year before that article: Vista's 11 Pillars of Failure. (April 21, 2008)
Some of John C. Dvorak's complaints:
6) Bogus Vista-capable stickers.
7) Missing drivers.
8) Conflicting advice.
11) Performance. You're not supposed to deliver a new operating system that's been in development for more than four years yet performs worse than the previous OS.
A Slashdot comment I wrote 10 1/2 years ago: Microsoft: "The whole world is our beta tester." That comment was way too positive, I realize now. Part of that comment seems correct to me:
"Another problem at Microsoft is apparently that the good people have left, and the people who remain are not knowledgeable enough to do the work."
It's time to stop joking about the many, many problems at Microsoft. (Regarding the parent comment: Cocaine will not fix the problems.)
Microsoft needs a new CEO and a re-organization of management.
See my comment posted yesterday: Microsoft is poorly managed? Plenty of evidence.