$ATTRIBUTE_LIST support?
LINUX based utility for use with gnuddrescue to aid with data recovery
Brought to you by:
maximus57
Menu
▾
▴
Hello,
challenges never stop :) I got an interesting drive, -- its attribute 0x80 of MFT does not fit into single MFT record because of heavy fragmentation, so here appears attribute 0x20 (ATTRIBUTE_LIST), which contains offset and length (in the same runlist format) where remaining attributes are. ddru_ntfsfindbad currently does not know about that. So if you had time I could send needed structures to you. Next message will contain pdf file attached which describes that attribute (the very last). Thank you!
Here is the description file
I will look into this when I get time, which might not be for awhile due to recent events. This will be another thing that might be difficult for me to test without having a drive that has this condition. I am not surprised something like this could happen as there are a few things that I have not accounted for out of lack of understanding at the time of creation.
I have looked into this, and at this time decided that I am unable to reproduce the conditions to accurately address this issue. It should be extremely rare for the data attribute of the $MFT to not fit into the record, so I am not going to pursue it until I have encountered a situation where I can properly test it.
Here is a link that has a little more info about it. But without having the actual condition available to myself, I am unable to work on this. You finally found something I can't do, yet...
http://inform.pucp.edu.pe/~inf232/Ntfs/ntfs_doc_v0.5/attributes/attribute_list.html
P.S.
I do have a disk that has about a dozen or so inodes that have the 0x20 attribute, but it appears to be because those files are linked to multiple folders and require multiple 0x30 name entries to relate to the different parent inodes. I couldn't find any 0x80 data entries that spanned more than one inode.
I created some "test case" based on real partition. In this archive you'll find text file long_mft.txt (actually ntfscluster logfile which I created for this MFT) and many binaries that are parts of MFT. Their name is an offset from partition start in clusters. bootsector (0.bin) and 0x20 non-resident attribute (12160369.bin) are included too, of course. I think that it is possible to create a sparse file and then populate these binaries in it. Hope this will help to solve a problem :)
I found some time to work on this, and did use what you supplied to create a sparse image file. I have made some progress on it, however it is apparent that it will require some major coding changes to implement properly. So it has been put back to a low level priority. It shouldn't happen often, and I also noticed that the disk must have been created by an older operating system (pre-XP). I am still keeping it in the list of things to do, when I can get enough time.
BTW, I've seen 0x20 attributes in files where new data is often appending to the end by small portions(some databases for example), and partitions where it exists were created by something WinXP or Win7-aged. Anyway, ddru_ntfs* is really a salvation in many cases for me, thank you for it :)