NTFS Corruption on Win10
twitter.com
twitter.com
The stuff about icons is just using a filetype to trigger the bug quickly by forcing windows to look up the path embedded in the icon.
Also: With twitter starting banning random accounts, like sci-hub, seemingly without any consistent justifications, shouldn't we reconsider twitter as valid source for HN news-stories?
Edit: seemingly different bug. Twitter is still all over terrible though.
There is a wide variety of research published only on Twitter, precisely because the publishing process is so lightweight for writers, and every single paragraph can form the leaves of a single giant conversation. A high quality Twitter thread cannot easily be replicated using alternative media
Maybe webmention needs the ability to reference parts of a page, although I guess you could do that by linking to an anchor.
What it seems to do is trigger a consistency check for the next reboot and some alarmist notifications. This is probably a simple check assertion somewhere which is seeing unexpected data passing through a call.
That is a problem but significantly less of one than actual corruption.
If anyone has evidence to the contrary and steps to reproduce it I’d be interested to try them.
That is very frequently the case with these kinds of filesystem bugs. You need actual hardware, not a VM. FWIW, it does seem to be reproducible on hardware.
It's an NTFS issue, i.e. a software issue. NTFS doesn't care if the underlying disk is virtual or bare metal. In fact, it kinda runs on virtual disks already even on bare metal, i.e. disk partitions (maybe even with a layer of encryption in between). There could be potential issues of course where you could get NTFS to trigger some hardware bugs, but that doesn't seem to be the case here, instead it is about accessing NTFS $I30 attributes.
* Different timings accessing a raw device compared to a virtual drive.
* The presence of the host scheduler can also alter timings.
* CPU configuration on the guest that's not typical on a bare metal (single CPU VM?)
It's not at all obvious that a bug must manifest the same way on a VM than on bare metal, although probably more often than not that's the case. If filesystem testing is also done on VMs then that would explain how this slipped through QC.
The bug is, if you write garbage data into a file "name" similar to those holding filesystem internal metadata, the filesystem driver detects this and mistakenly thinks the file could be the real metadata, so it does a consistency check on it, and because it fails consistency check, it sets a "volume needs fsck" flag. Windows (after 18H2) then show an alert. The alert is extremely confusing (it literally says "disk corruption") to the user, hence all the buzz.
This seems to be a deterministic bug tho. Open "special" file path to an $I30 attribute stream, crash and burn.
This was a single test so the veracity of the outcome is somewhat debatable.
If it's something along these lines, it may not be reproducible in a VM (where the host is responsible for waiting around for flushing delays)
Could be that the MFT is not flushed to disk after that event? That would suggest anything after the event would be broken. Also in line with my worries that this should be a bugcheck/panic rather than a soft assertion.
Tested it three times. Two of the tests, chkdsk ran and Windows booted after.
Third time, after chkdsk it went into Windows startup repair, and ultimately led to a green screen where it wouldn't launch boot further.
One complaint is I’d expect something at the level of MFT corruption to trigger a bugcheck (panic). Doesn’t seem safe behaviour to let the system carry on with a corrupt MFT.
Also, it presents one of the rare cases where running chkdsk might actually do something useful.