NTFS: Support $DATA consisting of multiple non-resident attributes

Project:JNode FS
Category:bug report
Assigned:Daniel Noll

I have found a case where $MFT's $DATA was spanned across multiple non-resident attributes. The first had only 4 sectors of information in it, and pointed at the main records in the $MFT (all the magic ones starting with $). The second had the remainder of the MFT's data, some 10,000+ file records worth of data.

As a result, attempting to get any directory (other than /) resulted in failure.

I'm working on a fix, and it will eliminate Issue 998 at the same time so I'm going to close that one in a minute or so.

Presumably the same can happen with any highly fragmented file, although I have only seen it on the MFT myself. I get the feeling it might also happen for indexes but I'll leave solving that until there is an instance of it.


Category:feature request» bug report

Changing category to bug report ... might as well reflect the end result, which is losing visibility of data.

Progress update. Smiling

I added support for reading multiple non-resident attributes, but ran into subsequent issues which made things fall over.

First issue was that the MFT had stored the rest of its records in MFT #15 (0xf). There was a bug where reading a chunk right at the end of a cluster would incorrectly compute that it needed to read 2 clusters when it really needed to read 1. As a result, it decided to find the next data attribute, which caused a StackOverflowError. Fixing the maths there made it read exactly the right number of clusters.

Then I hit the second issue, which is that the second data attribute claims to have VCN 0 when it is really at VCN 4 (the first attribute had length of 4.) I fixed that by decrementing the offset passed in for each subsequent attribute.

Now it seems like everything is working as expected. In the process of doing this I fixed the logging level of a few things, added a few toString()s to make debugging life easier and so forth, so that will all be in the same patch. I'm now in the clean-up phase anyway, it's been a long 3 days (almost 24 hours of time in the debugger...)


I just closed a couple of other issues which turn out to be fixed by the work I've been doing.

By the way, is it normal that I can't change the Status to "fixed"? There was another bug which was committed, but the person who committed didn't set the bug to fixed and I couldn't change it to fixed either.


Status:active» patch (code needs review)

Attaching my patch.

Includes the attribute list changes from issue 2007, plus a port of changes on our local branch backported to current trunk, plus any glue required to fit them together.

If this winds up being committed first then issue 2007's patch will become slightly simpler (and vice versa.)

ntfs-data-in-multiple-attribute-lists.patch39.81 KB


Thank you, Daniel. I have committed the patch. I don't have the possibility to test these particular features but I assume your usecases give it enough testing.
Could you please create new patches for issue 2007 and for any other issue that might be pending?
Regards, Levente


Cool, thanks for that. Tomorrow I'll rework 2007 against this patch and see what else we're sitting on which still hasn't made it into trunk yet.


Status:patch (code needs review)» fixed

According to comment #4 levente commited this. Marking fixed.


Status:fixed» closed