ntfs icon indicating copy to clipboard operation
ntfs copied to clipboard

MFT may have an attribute list

Open main-- opened this issue 1 year ago • 1 comments

I am trying to open a volume where this crate fails to open every file beyond the well-known ones (i.e. FRN > 16). Digging into the code a little, I found this:

https://github.com/ColinFinck/ntfs/blob/cf4c127268cdceb2a9f17503dc3fb014071a386c/src/ntfs.rs#L93-L100

It turns out that the MFT in my volume does have an attribute list. And taking a peek at ntfs-3g (1, 2) suggests that:

  • once $Mft/$Data is full, an attribute list is used
  • ignoring the attribute list is only guaranteed to give you a big enough chunk of the MFT to find that attribute list - not for other files
  • therefore, Ntfs::file must read the attribute list

I tried playing with the code here to call find_attribute instead of find_resident_attribute but a problem is that find_attribute invokes file (infinite loop). When I work around that, I can actually access all the files - but the FRNs are offset by 16 (i.e. looking up FRN 770 returns FRN 786). Given that the first 16 FRNs are in the resident portion of the MFT, this makes sense - though I'm not sure if this might be a bug in NtfsAttributes. The code there mentions concatenating attribute entries inside an attribute list, but the situation I'm observing here suggests that attributes from inside and outside an attribute list should be concatenated as well.

main-- avatar Mar 26 '24 13:03 main--

I implemented a potential solution for this in 0f0c66d0e4ed466e504c42eb8fd9679ed6cd9890. It works, but the lowest_vcn workaround is a bit weird.

main-- avatar Mar 28 '24 16:03 main--