( bzt | 2023. 12. 15., p – 10:07 )

ext2/3/4: gratula, nem semmi. par eve en is irtam ext-valamelyikhez egy adatmentesi projekt miatt de nagyon nem egyszeru a felepites (pl. extentek miatt) es sok opcionalis feature van amit le kell kezelni...

Ja, az extentekkel én is szívtam (Tso bácsi biztos sokat csuklott miattam), amíg rá nem bukkantam erre. Ebből a leírásból egyértelművé vált, hogy bár fának hívják, rohadtul nem is fa (egy fa esetében ugyanis az fájloffszet bitjei alapján lehetne kiválasztani a részfákat, na itt semmi ilyesmi nincs). Miután tisztázódott, hogy ez csak egy túlbonyolított lista, amit csak O(n) alatt lehet bejárni, meglett pár sorból az egész (mindössze 16 SLoC).

ntfs: iden nyaron ahhoz is irtam, foleg a tomoritett fileok kezelese nagyon trukkos tud lenni, bar azt nem hiszem hogy neked erdemes tamogatni. anelkul nem akkora gaz azert.

Jajj, de jó, egy szakértő!!! Nem bánod, ha kérdezek párat? Van egy-két dolog, amit sehonnan nem bírok kihámozni (néztem itt, itt meg itt is, de nem derült ki).

1. Szóval fogom a boot szektort, abból kiolvasom a kluszter méretét meg az mft kezdő kluszterét.
2. Beolvasom innen az első klusztert
3. fogom a legelső MFT rekordban (ami önmagára az MFT-re mutat) megkeresem a $DATA attríbutomot, amiből kihámozom azt a kluszterlistát, hogy az MFT-t hol tárolódik a diszken.
4. miután megvan ez a kluszterlista, azt használva egy folyamatos, összefüggő bitkolbászként láthatom az egész MFT-t, mintha egy fájl tartalma lenne.

Na és innentől nem világos. Hogy találom meg az N.-dik MFT rekordot? Teszem azt a gyökérkönyvtár fid-je 5, tehát az 5. MFT rekordot? Használható erre a boot szektor beli MFT rekord méret (N * boot_mft_entry_size) mint fájloffszet? De ha ez így van, akkor meg miért van minden MFT rekord fejlécében tárolva a mérete? Lehet, hogy muszáj végigiterálni, for(i = offs = 0; i < N; i++, offs += mft->allocated_size);, hogy meglegyen az N. rekordhoz tartozó fájloffszet? Ami tesztet végeztem, ott minden egyes rekordban az allocated_size megegyezett a boot_mft_entry_size-el, na de ez biztos mindig így van?

Ha valamelyik MFT rekord mérete esetleg mégsem a boot szektorban megadott (allocated_size > boot_mft_entry_size), akkor az csak simán folytatólagos, vagy pedig van benne egy újabb MFT header, amiben a fid ugyanaz, mint az előző rekord esetében? (Magyarán igaz az, hogy minden N * boot_mft_entry_size pozíción egy MFT header található, még akkor is, ha több rekord tartozik ugyanahhoz a fidhez?)

Hogy kell listázni egy könyvtárat? Pl. ha a gyökérkönyvtárat akarom kilistázni, akkor fogom az 5. MFT rekordot, dekódolom a $DATA attribútumát, és végigmegyek a tartalmán, vagy pedig az MFT-n kell végigmennem és kikeresni azokat, ahol a $FILENAME attribútumban a parent 5?

És ha már $DATA attribútum, ez mégis hogy tárolja az allokációt? Akármit nézek, a kezdő VCN mindig 0, minden MFT rekordban, mégis hogy derül ki ebből, melyik kluszteren tárolódnak az adatok?

meg amivel en rengeteget szivtam, hogy az MFT szektorok (512 byteos blokkok) utolso 2 bytejat lecsereli egy checksumra, es azt vissza kell patchelni (az MFT elejen a fixup bytes resz) mielott parsolod az MFT-t. ez valahogy az ntfs doksikbol kimaradt :(

Oh, ez roppant hasznos tanács! Figyelni fogok rá! Ez egyébként csak az MFT adatokra vonatkozik, vagy a fájltartalomra is (ha resident, azaz a fájl tartalma az MFT-ben van)? Vagy lényegtelen, mert csak menjek végig a fixup listán és cseréljem le az értékeket, akármi is az offszetjük, igaz?