Diskuze: Přepsáno prvních 19,5 MB disku
V předchozím kvízu, Online test znalostí Assembler, jsme si ověřili nabyté zkušenosti z kurzu.

Neregistrovaný

Zobrazeno 6 zpráv z 6.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
V předchozím kvízu, Online test znalostí Assembler, jsme si ověřili nabyté zkušenosti z kurzu.
Ahoj,
pokud těmi zálohami, co NTFS dělá, myslíš soubor $MFTMirr, tak do něj se myslím zálohuje jen prvních 16 záznamů Master File Table (což je ta databáze, kterou zmiňuješ). Měl byses z ní dozvědět, kde se Master File Table nachází, takže by jsi měl být schopen její části najít a zreonstruovat. Neznamená to ale, že zachráníš všechno. Záleží, jak velkou část MFT jsi tím přepisem 19 MB disku zničil.
Problém trochu je, že informace o položkách v adresářích se obvykle neukládají do MFT (pokud je počet položek adresáře vyšší než 2-4), ale zabírají další clustery. A tyhle clustery také mohou být přepsány. Ale zas až takový problém to asi není, protože zničením těchto clusterů nepřijdeš o data, jen o hierarchii souborů a složek.
Záznamy v MFT lze detekovat i automaticky, protože začínají signaturou FILE. Záznamy s informacemi o položkách adresáře začínají signaturou INDX.
Bohužel nevím, jak tento krok provést automaticky (tzn. pomocí nějaké utility). Na ruční řešení nemám ani hotový program ani čas ho tvořit, i když tu mám základ NTFS parseru v C++ hotový (už několik let).
To, že se jedná o externí disk, vidím jako výhodu. Kdyby sis takhle přepsal hlavní disk, kde máš na nějakém oddílu i operační systém, byl by mnohem větší průšvih. Takhle máš aspoň funkční stroj.
Moje zkušenosti na toto téma jsme kdysi dávno shrnul v článku:
http://www.secit.sk/…m-formatoval
Pokud to tvůj kamarád dokáže opravit, velmi by mě zajímalo jak a čím.
Měl jsem pravdu já. Brácha mi to vytýkal - bylo to triviální - opravila to obyčejná Windowsácká kontrola disku. Příště se spolehnu jen na sebe.
Vždyť netušíš o co šlo. Zaprvé mi bratr tvrdil, že je potřeba MBR i pro jeden partition - že je na něm identifikace disku. Dále, že NTFS na disku nemá zálohy systémových souborů. A dále, že se to ve Windows nedá tak snadno opravit, jak jsem si představoval. Hádali se mnou kvůli tomu celý víkend. Pak jsem zašel za kamarádem, který spustil obyčejnou kontrolu disku a potvrdil vše, co jsem hájil ty 2 dny. Tak mi nevykládej nic o egoismu. Takové ptákoviny, jako, že popis disku je v MBR fakt nehodlám poslouchat. Popis je vždy v ROM. Atd.
Takové ptákoviny, jako, že popis disku je v MBR
MBR si o každé partition pamatuje její typ, což u primárních partition znamená obvykle souborový systém, kterým je formátována. Jedná se o pátý bajt záznamu o oddílu. Hodnota 07 znamená NTFS. Myslím, že je ale Windows schopen poznat bootsector pro NTFS, i když dané zařízení nemá MBR. Ale nikdy jsem to nezkoušel.
že je na něm identifikace disku
Ano, je na něm identifikace disku (bajty 440-443, číslováno od 0), která se používá při mapování diskových oddílů na písmena, pod kterými jsou přístupné. Mrkni se do klíče:
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
Na Wikipedii v tématu "Master Boot Record" popisují formát některých hodnot v tomto klíči. Pokud disk nemá MBR, žeší se mapování zřejmě jiným způsobem.
Dále, že NTFS na disku nemá zálohy systémových souborů
Nevím, jak systémových souborů. Má zálohy souborů s metadaty ($Mft, $MftMirr, ., $Bitmap...), takže pokud poškodíš jen začátek MFT a systémové soubory jsou až trochu dál, tak obnovením MFT z $MFTMirr se "obnoví" i systémové soubory. Ale je možné, že Windows nějak zálohuje i systémové soubory, takhle do hloubky jsem tyhle procesy nezkoumal.
Zobrazeno 6 zpráv z 6.