MFT may have an attribute list

[main--]

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:

ntfs/src/ntfs.rs

Lines 93 to 100 in cf4c127

	// The MFT may be split into multiple data runs, referenced by its $DATA attribute.
	// We therefore read it just like any other non-resident attribute value.
	// However, this code assumes that the MFT does not have an Attribute List!
	//
	// This unwrap is safe, because `self.mft_position` has been checked in `Ntfs::new`.
	let mft = NtfsFile::new(self, fs, self.mft_position.value().unwrap(), 0)?;
	let mft_data_attribute =
	mft.find_resident_attribute(NtfsAttributeType::Data, None, None)?;

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--]

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