Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
8KB of data garbled at 2TB boundary #51
First, thanks for dislocker, it's great to be able to read BitLocker disks on Linux!
I have a 4TB BitLocker volume that I created on Windows 10. I checksummed 1.8TB of files on this volume, and found a single file that dislocker appears to be reading incorrectly. Specifically, two 4KB blocks in the file appear to be garbled. Windows 10 reads the file correctly (tested twice on different weeks) while dislocker reads the file incorrectly (tested twice across two physical-power-off events).
I built dislocker@develop 564420c on Ubuntu 15.10 (64-bit).
I booted into Windows 10 after seeing the incorrect hash
On a known-good copy of the data created on Windows 10, copying into a Linux Samba share:
Is there any other debugging information that might be useful?
Do you think it might have run into a BitLocker metadata header? I see those are also 8192 bytes.
The corruption is ~568,303,648 bytes into a 605,594,334 byte file.
Probably not a surprise BitLocker metadata header. I checked and I have headers at the three metadata header offsets listed, but not near the 2905324924928 and 2778237616128 positions listed in the strace. (Though I wonder why ntfs-3g is reading from two completely different positions for an unfragmented file?)
On a fresh mount.ntfs-3g process that hasn't cached any data yet, doing a read of the garbled 8KB section shows this strace:
The data read is at 2199023247360, which is exactly at the 2TB boundary:
Running dislocker with DEBUG logging shows this when reading the troubled 8KB section:
It looks like it's calling into