Paul wrote:
I ran into this error today, while making a backup
of the Win10 Insider HDD. It seems the $BITMAP
information is incorrect on the Insider. This causes
a problem with Macrium Reflect (and potentially other
software of the backup persuasion).
https://knowledgebase.macrium.com/di...uild+18234+Bug
The thing is, Microsoft has been maintaining the
release number on the NTFS file system at 3.1 all
through the Win10 period. Indicating that all the
modern OSes are using *exactly* the same file system
features.
It has not been indicating that the design of the
file system has changed.
There's basically no version control, over what
file system features have been buggered with.
First it was the $MFTMIRR getting broken.
Then, it was addition of some Reparse Point types,
which seem to be handled by other OSes OK, but
the other OSes, if you run CHKDSK, may do weird things
to the partition. I don't really feel all that
comfortable about that one. I don't dare run WinXP
CHKDSK on an NTFS partition that's been over in
the Win10 machine, because I no longer know if that
is safe.
And now, it appears that (perhaps) the $BITMAP is
being lazy-evaluated, to avoid "wearing" an SSD by
writing that part while the OS is running.
By not writing it, if the OS crashes or there is a
power failure, what protects that field ? Can the
Journal be relied on, plus boot-up cleanup actions,
to restore the $BITMAP properly ? Is there some
nice web documentation from Microsoft on the
subject ?
*******
OK, so they caused my copy of Macrium to fail. This
means I'm forced to bump up the version of Macrium, to
cover that disk.
Then, when 1903 is released, it's going to have that
"bug" in it. The problem then spreads to all the Win10
installs which will be upgraded in a month or two.
Macrium claims some backup software already calls
an API, in place of reading the $BITMAP directly,
and they will get the right answer. But which programs
do that ?
*******
And then the question is, why should we be trusting
Microsoft exactly ?
1) Changing a spec, without updating the version number.
2) Seemingly causing "partner" companies to chase
after them with a mop and pail. VirtualBox went
through hell maybe a year or more ago, and like
Macrium, didn't make a big stink about the extra
labor entailed.
3) Destroying trust from an end-user perspective,
by adding more and more "special handling" procedures
for the "rolling release OS".
I'm rapidly losing the ability to keep track of what
I should be doing!
To give a vivid example, if I boot Win10 and have
data disks connected, Win10 *will* damage the $MFTMIRR.
Then, I have to run Win7 CHKDSK to repair it. The
CHKDSK log makes no mention that the $MFTMIRR was
repaired, but it has been. So when I'm planning
procedures, I have to remember:
29) *Don't* boot Win10, while the data disks are
connected, or you'll have to slide the Win7
disk back in, boot up, and CHKDSK all the
NTFS partitions.
Such is life,
Paul
From that article, the patch they show for the Home (payware) version of
Macrium Reflect that I have and for Windows 10 x64 is:
http://updates.macrium.com/reflect/v....3570x6415.exe
Well, all of them show the same filename up until the last 5 characters,
which a
x86 (32-bit OS)
x64 (64-bit OS)
xx Macrium Reflect edition (00 = free, 15 = home/workstation, 20 =
server, 25 = server plus)
The patch version is same for all of them: upgrade from 7.1.3317 to
7.1.3570. I checked on my Win 7 x64 Home host and Macrium Home is at
7.2.4063. So, my Macrium install is already a minor version later (.2
instead of .1). With its auto-check option enabled, Macrium Reflect
tells me when there is a new version available, and I remember updating
it a couple weeks ago, and maybe a month, or two, before that.
The article you mention is dated back to September 08, 2018: more than 6
months ago. You should've been notified 5 times since then about more
updates since then unless you disabled Reflect's update check.
http://updates.macrium.com/reflect/v...ls7.2.4063.htm
That's a release history of updates. Don't know if it is a complete
list. It goes from 7.1.3317 to 7.2.3811 - which skips the patched level
of 7.1.3570. No mention of "bitmap" in that release history. If you
updated to any of the 7.2 versions, you got the patch already.
https://knowledgebase.macrium.com/di...um+Reflect+7.2
There was nothing there about the $BITMAP fix. There is mention of a
change in their CBT (Changed Block Tracker) driver.
https://knowledgebase.macrium.com/di...+Block+Tracker
However, I don't see their tracking feature is related to the $BITMAP
record or its attributes within NTFS.
The patch, if coded correctly, should *not* install if you have a
version of Reflect later than 7.1.3570, especially since you should
already be on 7.2.
Plus Macrium's article addressed the *Insider Build* of Windows 10.
That doesn't mean the bug was exhibited in the release build. From the
Macrium article:
For the $BITMAP record the $FILE_NAME attribute contains incorrect
size information. This would appear to be a problem with, or an
undocumented change to, the NTFS driver shipped with the OS.
The fault isn't with the NTFS specification or implementation but with
whatever is writing the values into those fields (attributes) of the
$BITMAP record. It isn't NTFS that is broke. It is the driver that
came with that pre-release, er, Insider build of Windows 10. Well, if
you choose to run the Insider builds then you also choose to be their
unpaid voluntary alpha tester (versus the released builds which have
users operate as unpaid involuntary beta testers). Insider builds
should not be installed on mission-critical, important, or daily-use
hosts. That's for tinkering, like having your regular commuter car but
a clunker sitting in the garage on which you tinker and proclaim that
one day you'll get all fixed and spiffed up.
The problem isn't with NTFS. It's with the driver in the Insider build
(back then) that writes into the NTFS records. I can give you a form to
fill out. Just because a form field says "First name" doesn't preclude
you, the writer, from entering you age in that field. So, as for the
real cause of the problem - the Insider driver - did you check if it
made it unchanged into the release builds?