Bogdan wrote: > On 08.06.2012 15:07, Jean-Pierre André wrote: >
[...] >> Not fully, I still get an error : >> >> Extents: Can't map ntfs_runlist (inode 22865232) >> >> (and of course, there are fewer than 22865232 nodes >> on this partition). >> > The displayed value was a pointer, fixed now. Apply over previous > patches. > Same results as before. However I now get a valid inode number : Extents: Can't map ntfs_runlist (inode 197) To be precise, a big-endian computer chokes before reaching that point, but while processing the same inode (131, which 197 is a part of). > The loop should take (and wipe) the data attribute of each extent. > In the above situation, there is a single data attribute whose runlist requires 10 extents (the tail of the attribute being obviously described in the last one). > My question was: is it enough to call > ntfs_inode_attach_all_extents(ni)? Should I call > This gathers the list of all the extents of the base inode. It is only meaningful for a base inode. > ntfs_attr_map_whole_runlist(na) just on the first data attribute? > You should do so for each attribute which can have a runlist. For each such attribute you should make a single call, even if the attribute needs several extents. You probably cannot process an extent individually, as the attribute size (needed to locate the tail) may be described in another extent. > Should I call ntfs_attr_map_whole_runlist(na) for each attribute? > Only some attributes can have a runlist (the most prominent ones are the data attributes and the index_allocation ones, you may probably ignore other attribute types). There is a field in the header of MFT entries to tell whether the entry is an extent of another inode. Regards Jean-Pierre ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ ntfs-3g-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
