Windows – Determine filename at an LBA (NTFS)

I'll answer the title question nothing more.¹

First, do note that, if the sector is truly bad, unmarking it won't make it readable. So your cloning software is likely to choke on reading it instead.

In NTFS, a cluster is marked as bad by assigning it to a special stream, $BadClus:$Bad, a sparse file.

What you need is to

• edit its runlist to remove the corresponding allocated block(s)
• mark the corresponding cluster(s) as free in $Bitmap.

• To unmark all bad blocks, there's ntfsfix -b -d (-b=clear bad block list, -d=clear/don't set "dirty" flag) (another method with ntfstruncate does exactly the same²).

  • It might introduce minor inconsistencies into metadata (in my case, a few indices apparently became unsorted), I'm not sure why, so either run chkdsk -f by hand or omit -d to trigger it at Windows startup if / in case you get FS errors.

• To clear a specific block is much more difficult since I didn't find any existing software that can do this out of the box³. NTFS Bad Sectors Resolution: The $BadClus metafile - Katy's code describes the way - basically, it's editing the runlist and bitmap by hand.

¹ _{Only because handling bad sectors + NTFS + cloning is too broad a topic. I'll gladly answer ones directly related to the matter at hand.}
² _{checked the source code of ntfsfix v2015.3.14.}
³ _{for the insistent ones, these can't do it: ntfscat(can't read unreadable sectors),ntfscp(can't write to offset), ntfstruncate,ntfsfallocate,dd(can't open $BadClus:$Bad for writing)}

This information is accessible through the Defrag API. Third-party defragment tools might expose it. On recent Windows systems (8.1 works, 7 not tested) you can use fsutil to query it:

C:\>fsutil file queryextents example.txt
VCN: 0x0        Clusters: 0x2        LCN: 0x18f85e

There is also another subcommand that dumps all information for all data streams in the file:

C:\>fsutil volume filelayout example.exe

********* File 0x01390000000008dd *********
File reference number   : 0x01390000000008dd
File attributes         : 0x00000020: Archive
...
Stream                  : ::$FILE_NAME
    Attributes          : 0x00000000: *NONE*
    Flags               : 0x0000000c: Resident | No clusters allocated
    Size                : 80
    Allocated Size      : 80
Stream                  : ::$DATA (the main data stream)
    Attributes          : 0x00000000: *NONE*
    Flags               : 0x00000000: *NONE*
    Size                : 1681920
    Allocated Size      : 1683456
    Extents             : 1 Extents
                        : 1: VCN: 0 Clusters: 411 LCN: 8527618

In both commands' output, for each "extent" (a contiguous range of clusters), you get the "virtual cluster number" (offset from beginning of file), number of clusters in the extent, and the "logical cluster number" (offset from beginning of volume).

Note: Tiny files, which fit in the MFT base record, are stored ("resident") in their MFT record and will have zero extents. For those, you'll need to use other ways to dig through the MFT itself. (Also, in some cases, the file may be sparse and only have a small part allocated on disk; the rest is just assumed to be null bytes.)

The clusters are filesystem-level, so you need to convert them to block-device-level sectors; my system has 8 sectors per cluster:

C:\>fsutil fsinfo ntfsinfo c:
...
Bytes Per Sector  :               512
Bytes Per Cluster :               4096
...

C:\>set/a 0x18f85e * (4096 / 512)
13091568

C:\>set/a 0x18f85e * 4096
6702882816

This means you can open \\.\C: with HxD or such, and find beginning of file at sector 13091568 (or byte 6702882816).