Wow, mennyi hasznos infó!
arra figyelj hogy az MFT entry size nem mindig 1024 (bar ez a leggyakoribb), es a szektor meret se mindig 512 byte
Jaja, ezt most így számolom ki (az sb->mft_entry_size int8_t, azaz előjeles):
clu_size = sb->bytes_per_sector * sb->sectors_per_cluster_block;
mft_entsize = sb->mft_entry_size > 0 ? sb->mft_entry_size * clu_size : 1 << -sb->mft_entry_size;
A hexdumpban 0xF6-nak látom az sb->mft_entry_size-t, és ez így 1024-et köp ki az mft_entsize-ra.
igen. ha nem fer bele egy MFT blokkba egy file osszes adata, akkor tobb MFT blokk lesz, mindegyik sajat headerrel
Ezt miért nem bírták beleírni a doksikba? Kösz! Ezek szerint akkor az N * mft_ensize nem járható út, marad a O(N)-es végigjárás, hogy megtaláljuk az N. fidhez tartozó rekordot. Nagyon hasznos tudni, köszönöm!
persze az is jarhato hogy a parent-re szurve vegigmesz az MFT-n
Ezt azért mellőzném ha lehet. Ezek szerint lehet :-)
Na, akkor már csak azok a fránya VCN-ek nem világosak. Elvileg ha a kezdő nulla, akkor érvényesek a méret adatok az attribútumban, a vége adja meg a run-kódolt kluszterek számát, és a run legelső tagja abszolút kluszterszám, míg a továbbiak relatívek. Ez tiszta. Na de mi van akkor, ha a VCN nem nulla? Ilyennel találkoztál már?