MS06-049 Causing Silent Data Corruption
Uncle Mike writes "It looks like there is a problem with the recently released MS06-049 / KB920958 patch. If you have compression activated on any folder, then the compressed data is at risk from corruption. New files that are close to a multiple of 4K in size will have their last 4,000 bytes or so overwritten with 0xDF. Although this problem has been reported to Microsoft, as yet there appears to have been no official announcement.
"
its interesting how when they make a patch that corrupts your data you dont hear anything from them.. but when someone makes a program to allow fair use by opening DRM on their movies they come up with a CRITICAL patch within ours to prevent it. i think that speaks to their priorities, protecting their drm IMPORTANT protecting your data hmm.. not so important
If you really have been programming for a long time, you must only be writing very simple programs if you've never had something like this happen, and you think that being "extra careful" is all you need to do to avoid it. What type of programmer does this? Every type of programmer - it's unavoidable.
The programmer is not to blame here. The real question you should be asking is "What type of QA department fails to catch a bug like this?"
This space intentionally left blank.
I agree and disagree with you. As long as the programmer properly unit tested his/her work, then you can shift blame to QA. I have seen developers not properly unit test their code too many times, relying on the QA department to do their work for them. But yes, unless it happens in very rare circumstances (is this the case?) someone should have caught this in testing somewhere... but not necessarily just QA.
IANAQAT (I am not a QA tester).
-- I ignore anonymous replies to my comments and postings.
What're your customers going to do?
Deleted
maybe one patch was just easier to write.
--
Carnage Blender : Meet interesting people. Kill them.
Made me think of Grannies Perls of Wisdom I read on Java Ranch (I first found it about 6 or 7 years ago...): "Testing can show the presence of bugs, but not their absence."
-- I ignore anonymous replies to my comments and postings.
...similar to their (in)famous debug version of the new operator (IIRC generates guard bytes set to 0xCDCDCDCD).
While they are doubtlessly not releasing images with debug info, they might be using an overriden new operator that does something similar (for a variety of reasons).
It is hard to say, but this type of error - while *not* acceptable, *is* understandable,
I am very small, utmostly microscopic.
Hopefully that's a joke. Pretty much nobody would put music on a compressed drive, as nearly ALL of the music formats in common use today are compressed. Rather heavily. Those music formats that aren't don't compress very well anyway.
Additionally, the thought that MS would release a patch that intentionally corrupts data is unthinkable, for ANY corporation. The civil (and possibly criminal, who knows) liabilities would be ENORMOUS.
Karma: Poor (Mostly affected by lame karma-joke sigs)
Maybe you should ask Linus... I seem to remember a released stable kernel that neglected to sync file systems before shutting down.....
I love Linux, hate Windows, but point it, sh!t happens.
I can't believe there were > 0 people who replied to Karma Farmer's comment thinking it was anything but an attempt at humour/troll, much less that any such poster would get their manties in a knot over it either.
Some software bugs manifest in rare cases, and can only be found by code inspection or luck. Unless you work with languages that allow 100% guaranteed mathematical proofs of correctness.
You don't just make /var/log a compressed filesystem...
I'm no MS fanboy, but... suppose the OS in question had some sort of directory-compression scheme that had a seven-year track record of impressive stability and effectiveness? Why not use it?
Disk compression earned a terrible rep back in the 90s, when DOS/Windows and Windows 95 themselves were so unstable there was no chance that it could work properly. But MS finally got it right when they swiped tech from Stacker and included directory compression in NTFS. I've never heard of anyone having a problem with it until now.
Back when I up my home Windows 2000 box, disk space was less cheap and I was more poor, so I've got some compressed folders to un-compress. Curse you, Microsoft! Stop screwing up the few things you've done well!
Why?
File system is handled by a kernel. File system compresses files before writing them to the disk, respectively decompresses them during read operations. Therefore, the compression is handled in kernel. Where would you handle it?
Data compression is not like black magic. As the matter of fact, the most data compression algorithms out there are mind boggingly simple and very well understood.
Of course you could move the file system into the user space, but that would introduce some bad performance penalty.