On 09.06.2012 19:22, Jean-Pierre André wrote: > > > 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)
That's good, the last patch corrected only displaying the inode number. > 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). That's bad. Even if I'm doing something very wrong, the library should manage to at least return an error. >> 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. From all this, I'm beginning to think that my change is not needed. The first call to ntfs_attr_map_whole_runlist() (before "close_attr:") should read the whole attribute, no matter how many extents it is in, right? If so, the first calls to wipe_compressed_attribute() or wipe_attribute() will wipe the tail before reaching the "close_attr:" point, so searching for and wiping the extents is not needed. Is this correct? Seems to work even for the "big" file (I can see my marker bytes after the content). -- Pozdrawiam/Regards - Bogdan (GNU/Linux & FreeDOS) Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro Grupy dyskusyjne o asm: pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32 www.Xiph.org www.TorProject.org Soft (EN): miniurl.pl/bogdro-soft ------------------------------------------------------------------------------ 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
