Some time ago I replaced a 160GB HDD with a 1TB SSD and used Samsung's Data Migration Tool to clone the drive. The original HDD had a 160 GB Windows 10 NTFS partition, and this was cloned to a 900GB partition on the SSD. The SSD now has 325GB of data, about double that of the HDD. The system has been running without issue for several years.

Recently I was examining various NTFS metafiles with DMDE. I noticed that the INDX record for the root directory contained a $Bitmap entry with an Allocated Size of 4886528 and a Size of 4883760. However, the corresponding $MFT record for $Bitmap reported figures of 27471872 and 27471448 bytes for the same parameters.

My first thought was that perhaps this was a sparse file. However, an examination of the file contents revealed the expected bitmap data, ie one bit per cluster, 1 = in-use cluster, 0 = free cluster.

The cluster size is 4KiB, so a 160GB NTFS volume should have a $Bitmap of size ...

(160 GB / 4KiB) / 8 = 4882812 bytes

For a 900GB NTFS volume, the size is 27465820 bytes.

So it would appear that the $MFT record reflects the size of the 900GB bitmap whereas the INDX reflects the 160GB bitmap. The used space is now double that of the original NTFS volume. Moreover, CHKDSK reports no errors.

This suggests that the $MFT record takes precedence over the INDX, and the INDX inconsistency appears to be ignored by CHKDSK.

_________________
A backup a day keeps DR away.

question is how that samsung tool migrates the data. I guess there might be a bug in that tool. Generally, INDX is just an index, probably only MFT record number is used to find file record of a file in a folder. Everything else is taken from the file record once found. This makes sense, MFT is the boss after all...

_________________
Adatmentés - Data recovery

What is CHKDSK doing, if not verifying the "linkage" between INDX and MFT? Or is it just walking down the file/folder tree via the INDX-es?

_________________
A backup a day keeps DR away.