3 ms·

I don't see why this bug would work any different in a VM than on a real bare-metal OS or disk? It's an NTFS issue, i.e. a software issue. NTFS doesn't care if

I don't see why this bug would work any different in a VM than on a real bare-metal OS or disk? 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.

steerablesafe 6y ago
I'm not a filesystem developer, but assuming the corruption is caused by a race condition in the filesystem driver the difference can come down to many aspects: * 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.
- rndgermandude 6y ago
  Sure, there are race bugs that can in theory be affected by things like that. This seems to be a deterministic bug tho. Open "special" file path to an $I30 attribute stream, crash and burn.
- rfoo 6y ago
  Sure, but there are no corruption at all. 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.

steerablesafe 6y ago

I'm not a filesystem developer, but assuming the corruption is caused by a race condition in the filesystem driver the difference can come down to many aspects: * 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.

rndgermandude 6y ago
Sure, there are race bugs that can in theory be affected by things like that. This seems to be a deterministic bug tho. Open "special" file path to an $I30 attribute stream, crash and burn.
rfoo 6y ago
Sure, but there are no corruption at all. 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.