1

Sysinternals Diskview is producing what seems like an unlikely situation. I have a series of files I know exist on an NTFS filesystem (which is on a spinning disk hard drive), but when I try to use the Highlight feature to find them it will most often report that The specified file does not occupy any clusters. I don't see how this is possible as the file is also included in the Export textfile output. Perhaps there are some limitations to this type of tool that I don't understand or something, but any advice or pointers would be helpful.

This task is part of an attempt to dd some files I'm looking for directly from the disk on a Linux machine.


update

Thanks for the pointers in the comments, the note about $MFT got me on the right track. Thanks!

Further background... I was in the process of backing up some old hard drives when I ran into a few pesky Permission denied failures. Most people probably would have stopped there, and I probably should have. Long story short, these are most likely encrypted with EFS or are possibly corrupted. The inability of Diskview to find the associated clusters was somewhat of a distraction, but probably could use an explainer for the filesystem novice. I'll take a stab at that part, and save analysis of the permission denied anomaly for another day.

$ tar czf - lab01/ 1> /dev/null
tar: lab01/lab01/.DS_Store: Read error at byte 0, while reading 6148 bytes: Permission denied
tar: lab01/lab01/.vscode/launch.json: Read error at byte 0, while reading 512 bytes: Permission denied
tar: lab01/lab01/lab01.ok: Read error at byte 0, while reading 247 bytes: Permission denied
tar: lab01/lab01/lab01.py: Read error at byte 0, while reading 3072 bytes: Permission denied
tar: lab01/lab01/map.jpg: Read error at byte 0, while reading 8192 bytes: Permission denied
tar: lab01/lab01/numberline_0.png: Read error at byte 0, while reading 3584 bytes: Permission denied
tar: lab01/lab01/numberline_1.png: Read error at byte 0, while reading 3584 bytes: Permission denied
tar: lab01/lab01/school.csv: Read error at byte 0, while reading 5120 bytes: Permission denied
tar: lab01/lab01/tests/.DS_Store: Read error at byte 0, while reading 5120 bytes: Permission denied
tar: lab01/lab01/tests/q22.py: Read error at byte 0, while reading 2863 bytes: Permission denied
tar: lab01/lab01/tests/q231.py: Read error at byte 0, while reading 1689 bytes: Permission denied
tar: lab01/lab01/tests/q232.py: Read error at byte 0, while reading 1046 bytes: Permission denied
tar: lab01/lab01/tests/q311.py: Read error at byte 0, while reading 1072 bytes: Permission denied
tar: lab01/lab01/tests/q41.py: Read error at byte 0, while reading 367 bytes: Permission denied
tar: lab01/lab01/tests/q411.py: Read error at byte 0, while reading 360 bytes: Permission denied
tar: lab01/lab01/tests/q51.py: Read error at byte 0, while reading 736 bytes: Permission denied
tar: lab01/lab01/tests/q52.py: Read error at byte 0, while reading 784 bytes: Permission denied
tar: lab01/__MACOSX/lab01/._.DS_Store: Read error at byte 0, while reading 120 bytes: Permission denied
tar: lab01/__MACOSX/lab01/._lab01.ok: Read error at byte 0, while reading 176 bytes: Permission denied
tar: lab01/__MACOSX/lab01/._lab01.py: Read error at byte 0, while reading 435 bytes: Permission denied
tar: lab01/__MACOSX/lab01/tests/._.DS_Store: Read error at byte 0, while reading 120 bytes: Permission denied
tar: Exiting with failure status due to previous errors
4

1 Answer 1

1

As kreemoweet pointed out in the comments, files that are small (possibly anything fewer than 1024 bytes) are likely contained entirely in the MFT. Generally this isn't relevant unless there is something broken or corrupted. If for some reason you care about this, the error message from Diskview regarding the file not occupying any clusters is a perfactly acceptable indicator that the file data is contained in the MFT. Examples of several more deliberate options are detailed below. The $DATA attribute is what we care about, and will have a flag for whether the data is Resident within the MFT itself, or located in a cluster. I still struggle with this because the MFT technically occupies sectors on disk, but identifying the structure of system files is something that Diskview does not do. And very few tools seem to refer to these resident files directly.

Linux/Unix option using ntfsprogs (ntfs-3g on .deb based systems)

in the MFT:

$ ntfsls -l -p /file1 /dev/sdb2 
      17 Jan 16 21:38 2021 file1
$ ntfsinfo -F /file1 /dev/sdb2 | grep -A1 \$DATA
Dumping attribute $DATA (0x80) from mft record 66054 (0x10206)
        Resident:                Yes

not in the MFT:

$ ntfsls -l -p /file2 /dev/sdb2 
    2768 Jan 16 21:38 2021 file2
$ ntfsinfo -F /file2 /dev/sdb2 | grep -A1 \$DATA
Dumping attribute $DATA (0x80) from mft record 67840 (0x10900)
        Resident:                No

Windows option using nfi.exe

Found this from this other similar questions answer. I should note the link for this package provided there was not available on microsoft.com anymore and I had to use archive.org.

in the MFT:

C:\oem3sr2\nfi>nfi.exe n:\file1
NTFS File Sector Information Utility.
Copyright (C) Microsoft Corporation 1999. All rights reserved.

\file1
    $STANDARD_INFORMATION (resident)
    $FILE_NAME (resident)
    $SECURITY_DESCRIPTOR (resident)
    $DATA (resident)

not in the MFT:

C:\oem3sr2\nfi>nfi.exe n:\file2
NTFS File Sector Information Utility.
Copyright (C) Microsoft Corporation 1999. All rights reserved.

\file2
    $STANDARD_INFORMATION (resident)
    $FILE_NAME (resident)
    $SECURITY_DESCRIPTOR (resident)
    $DATA (nonresident)
        logical sectors 102022152-102022159 (0x614bc08-0x614bc0f)

Subsequently if you wanted to view the file data from Linux, and for some reason wanted to look at it without mounting the device or image, the -v option to ntfsinfo does the trick. This will output a Runlist at the bottom that has the cluster numbers. Couple this with the cluster sizes and you have the physical offset we can seek to for dd goodness (although not much reason to if you can just use ntfscat). Thanks to this answer for a explainer on cluster-to-sector and byte-offset conversion. Again, the only reason why we might need to look at the data like this is because of a broken or corrupted filesystem. Likewise, there are many other tools that are possibly better suited to this type of analysis for eg. http://sleuthkit.org/sleuthkit/.

Find cluster info:

$ ntfsinfo -m /dev/sdb2 | grep "Cluster Size"
        Cluster Size: 4096
$ ntfsinfo -v -F /file2 /dev/sdb2
...
Dumping attribute $DATA (0x80) from mft record 67840 (0x10900)
        Attribute length:        72 (0x48)
        Resident:                No
        Name length:             0 (0x0)
        Name offset:             64 (0x40)
        Attribute flags:         0x0000
        Attribute instance:      2 (0x2)
        Lowest VCN               0 (0x0)
        Highest VCN:             0 (0x0)
        Mapping pairs offset:    64 (0x40)
        Compression unit:        0 (0x0)
        Data size:               2768 (0xad0)
        Allocated size:          4096 (0x1000)
        Initialized size:        2768 (0xad0)
        Runlist:        VCN             LCN             Length
                        0x0             0xc29781                0x1

The seek/skip position in bytes is the cluster number multiplied by the cluster size. Clearly this is where file fragmentation gets to be a problem!

$ dd bs=1 if=/dev/sdb2 skip=$(python -c 'print 0xc29781*4096') count=2768
...our data...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .