Ricostruire la FAT di un HD esterno (NTFS)

[Marco71]

Originariamente inviato da gonZales

Ok, scaricato.. stasera provo
ma sto programma ricostruisce anche la FAT?

..."New Technology File System" non esiste e non ha senso parlare di File Allocation Table.
Ti dico subito che sicuramente i dati utente contenuti nella tua unità esterna sono recuperabili...
Recentemente Kroll Ontrack è riuscita a recuperare oltre il 99 % dei dati contenuti su un hard disk Seagate da 400 GiB trovato tra i resti...l'unità era in dotazione allo Space Shuttle Columbia il cui disastro è tristemente noto.
Il problema dei 128 GiB è correlato all'indirizzamento tramite L.B.A che ha afflitto anche Windows XP almeno sino al rilascio del SP1 (con indirizzamento L.B.A a 48 bit).
Se non te lo hanno già consigliato mi permetto di consigliarti SpinRite versione 6 (a pagamento ma non costa molto).
La prima cosa che devi fare è "esporre" l'unità al diretto controllo del sistema centrale senza avere intermediazioni fatte ed operate dal circuito integrato "ponte" A.T.A/A.T.A.P.I<->U.S.B ma anche FireWire (tali I.C molto spesso nemmeno integrano in silicio tutto il set di comandi definito dalle specifiche del comitato T13).
Allo stato attuale i migliori "bridge" sono gli Oxford 911.
Ciao rеpne scasb...che intendi per "sovra saturazione" ?
Un esaurimento dei dati presenti in qualche registro interno ?
Tra parentesi se l'unità esterna è dotata di file system N.T.F.S (e non F.A.T come molti costruttori hanno la prassi di fare esponendo a gravi rischi di corruzione dati dovuta alla minore affidabilità oltre che alla mancanza assoluta di journaling con relativo log) una copia "speculare" dell'M.B.R oltre che della master file table si trova in corrispondenza della regione mediana della superficie.
Come ti ha detto repne scasb (questo nicknacme mi ricorda tanto una istruzione del set 80386 per la scansione di stringhe di bit con prefisso esadecimale 66h) la corruzione dei dati non necessariamente interessa e può interessare il settore di avvio dell'unità; può essere il risultato di moltissimi fattori :

1) i box esterni sono come la peste rossa per i collegamenti dei pin ai circuiti integrati...sottopongono i poveri piccoli "gufetti rotanti" ad uno stress elettrico e meccanico indicibile dato che nella maggioranza dei casi sono dotati di sistema di alimentazione elettrica e di controllo sull'hard disk collegato, penosi.

2) anche dopo che compare il rassicurante messaggio del sistema che informa che "ora è possibile rimuovere ..." allo spegnimento fisico del box il gruppo testine si trova quasi sicuramente ad affrontare il parking in condizioni di emergenza dato che i solerti costruttori ed assemblatori dei box in questione non usano I.C "ponti" dotati in hardware dei comandi per poter mettere in atto la corretta sequenza controllata di "messa a riposo" del gruppo testine.

3) eventuali corruzioni se verificate in fase di scrittura sono ancora più subdole e pericolose dato che molto spesso le scritture interlacciate (per magari interposizione di agente contaminante tra superficie e sliders porta testine) non permettono poi un ricupero dei dati nemmeno con i controlli tramite E.C.C.
A questo proposito l'unica contromisura è ad esempio quella posta in essere come si suol dire dalle procedure di read-after-write con comparazione tra i dati effettivamente scritti sulle superfici con i dati contenuti all'interno della memoria di "bordo" all'hard disk...tali procedure sono presenti però solo nelle unità S-A.T.A per uso R.A.I.D (come i Segate ES/ES.2) oppure in tutti i modelli 15K.5/15K.6 sempre Seagate.
E mi piangerebbe il cuore se mai vedessi un ES alloggiato in un "orrendo" box esterno.

Per il recupero dei dati ci sarebbe anche una altra opzione ma avresti bisogno di un microscopio S.E.M per usufruirne...tali metodi prevedono la analisi dei domini magnetici (registrati longitudinalmente o perpendicolarmente) e vengono di norma usati in ambito forense per recuperare evidenze comprovanti eventuali misfatti...solo un campo magnetico alternato ad elevata frequenza di intensità di varie decine di kA/m o magari una esplosione diretta di un "piccolo" ordigno come la bomba TZar da 56 MegaTon possono sicuramente evitare tali analisi...ed i cracker di oltreoceano ne sanno qualche cosa...
Grazie.

Marco71.

[gonZales]

Sono anch'io convinto che i dati siano totalmente recuperabili, anche perchè il fattaccio è durato pochi istanti giusto il tempo di trasferire un file dall'hd alla chiavetta collegati entrambi alla stessa scheda usb.. E' stato proprio questo (cioè collegare la chiavetta ad un'altra porta usb della stessa scheda [una scheda pci usb2.0 che ho aggiunto per sopperire alle usb1 della scheda madre], cosa che non avevo mai fatto) a incasinare il disco. Sembrava proprio la condizione descritta da rеpne scasb...
se non è colpa dell'MBR allora è per forza della MFT, o no?

[rеpne scasb]

Originariamente inviato da Marco71

Ciao rеpne scasb...

Ciao a te Marco71, ho letto alcuni tuoi interventi che reputo sempre molto interessanti.

che intendi per "sovra saturazione" ?
Un esaurimento dei dati presenti in qualche registro interno ?

La maggior parte dei chip di conversione USB<->ATA/ATAPI dispongono di buffer per velocizzare le operazioni di I/O. Una nuova operazione di I/O non potra' essere eseguita se prima non sia ha la sicurezza che il buffer interno sia stato correttamente svuotato. In alcuni rari casi, quanto il "traffico" sub bus USB e' assai sostenuto, puo' accadere che alcune informazioni contenute nel buffer interno non siano state correttamente trasferite (sovrasaturazione del buffer). In questi rari casi si ha una corruzione del buffer, con conseguente anomalia di funzionamento (il buffer oltre che dati puo' contenere anche comandi sia ATA che ATAPI (packet). L'insorgenga di queste problematiche dipende da vari fattori, non ultimo il controller USB impegato.

Come ti ha detto repne scasb (questo nicknacme mi ricorda tanto una istruzione del set 80386 per la scansione di stringhe di bit con prefisso esadecimale 66h)

In linguaggio macchina>80386, 66h e' un prefisso che indica una forzatura della dimensione-operando; ad esempio in real-mode/16-bit:

	MOV	AX,[BX]		; 8Bh 7h
	MOV	EAX,[BX]	; 66h 8Bh 7h

repne scasb e' identificato dall'opcode 0F2h 0AEh.

[Marco71]

...si ti ho parlato del prefisso 66h sapendo già di cosa parlavo...leggevo dell'80386 da quando fu presentato nel 1985/1986 sulla miriade di riviste che all'epoca popolavano le edicole (MC Microcomputer e le lezioni sull'assembly del Dr. De Prisco).
Tanto per dire e confermare che gli errata per i microprocessori (all'epoca con i gate dei M.O.S che che avevano lunghezze ben oltre il micrometro si poteva usare questo prefisso forse oggi sarebbe più consono parlare di nanoprocessori) sono sempre esistiti l'80386DX a 16MHz aveva problemi (gravi) proprio con una istruzione molto usata come IMUL.
Certo è che purtroppo il panorama dei bridge di conversione U.S.B/FireWire<->A.T.A/A.T.A.P.i è oggi molto desolante...nemmeno i fenomeni di buffer underrun hanno previsto in fase di progetto ?
Questa è anche la conseguenza scellerata dei time to market sempre troppo ristretti con correzioni (eventuali) dei "bug" quasi sempre in corso d'opera e quasi mai prima in fase di progetto (almeno per i costruttori di I.C meno "pregiati"...Intel dopo i problemi avuti con l'algoritmo S.R.T di alcuni modelli di Pentium ha intrapreso una politica di verifica "esaustiva" almeno delle f.p.u integrate nei sui processori x86...
Grazie.

Marco71.

[gonZales]

Originariamente inviato da Marco71

...si ti ho parlato del prefisso 66h sapendo già di cosa parlavo...leggevo dell'80386 da quando fu presentato nel 1985/1986 sulla miriade di riviste che all'epoca popolavano le edicole (MC Microcomputer e le lezioni sull'assembly del Dr. De Prisco).
Tanto per dire e confermare che gli errata per i microprocessori (all'epoca con i gate dei M.O.S che che avevano lunghezze ben oltre il micrometro si poteva usare questo prefisso forse oggi sarebbe più consono parlare di nanoprocessori) sono sempre esistiti l'80386DX a 16MHz aveva problemi (gravi) proprio con una istruzione molto usata come IMUL.
Certo è che purtroppo il panorama dei bridge di conversione U.S.B/FireWire<->A.T.A/A.T.A.P.i è oggi molto desolante...nemmeno i fenomeni di buffer underrun hanno previsto in fase di progetto ?
Questa è anche la conseguenza scellerata dei time to market sempre troppo ristretti con correzioni (eventuali) dei "bug" quasi sempre in corso d'opera e quasi mai prima in fase di progetto (almeno per i costruttori di I.C meno "pregiati"...Intel dopo i problemi avuti con l'algoritmo S.R.T di alcuni modelli di Pentium ha intrapreso una politica di verifica "esaustiva" almeno delle f.p.u integrate nei sui processori x86...
Grazie.

Marco71.

....aaaah!
bei tempi quelli....
nell'80, col mio c64 avevo iniziato a smanettare in assembler... gestire gli sprite, il sintetizzatore ADSR.... mi ero pure comprato un bel "mattoncino": Programmazione del 6502
..peccato non aver avuto più tempo..

[Marco71]

...nel 1980 io avevo solo uno Sharp Pocket Computer Pc1245...il VIC 20 costava una "cifra" astronomica per lo stipendio del povero mio papà...sigh...
Grazie.

Marco71.

[almaxy]

Scusate la mia intromissione, anche io ho uno dei seguenti problemi:
ho un secondo HD da 250GB(dati) partizionato in due. Durante una copia di grossi files ad un tratto il disco mi è andato in errore diventendo inaccessibile.
Praticamente una partiz. dove avevo gorssi files non me la vede + e l'altra non mi riconosce + il file system, credo che si sia incasinato MBR.
Come posso risolvere il probl.? Ho provato con testdisk 6.9 diversissime volte ma nulla. Mi piacere ripristinare l'HD allo stato originale, se possibile, mi piacerebbe tentare.
Nei 212 GB(circa) ho quasi 160 GB di roba .....
Questa è la situazione:



Si vede l'immagine?
Altrimenti: http://xoomer.alice.it/pioantonio/immagini/Gest_PC.jpg

[almaxy]

[gonZales]

Ciao,
..ti dirò che l'avevo provato anch'io il ripristino con testdisk, senza risultato purtroppo..
Ho sentito parlare bene di spinrite, però so che lavora solo sotto dos e non credo neanche si tratti di un programma alla portata di tutti (sicuramente non per principianti).
Io nel frattempo ho risolto (o meglio ho appena iniziato il recupero) con GetDataBack, un'ottima utility che ti fa una scansione approfondita del disco e ti permette di recuperare tutto il possibile (occhio alle versioni fat-ntfs).
Anch'io avrei preferito la possibilità di "riaggiustare" il file system, ma sinceramente mi sento già a cavallo potendo recuperare le cose importanti che avevo salvate...

[Lucamax]

Io ho avuto un problema simile ed ho risolto alla grande con Testdisk, davvero un ottimo programma, l'utilizzo forse non è immediato ma davvero un ottimo tool...

[hibone]

Per recuperare i dati personalmente mi trovo molto bene con RStudio.
anche se sarei curioso di provare qualcosina della salvation data...

piuttosto visto che si parla di "ricostruire la FAT di un NTFS" vi chiedo:

Per un hdd esterno ove non si tengano file più grossi di 4GB è preferibile usare la FAT o la NTFS ?

Mi interessava un parere anche sintetico ma comunque motivato sia in merito alla gestione dello spazio file, sia in merito ad un eventuale recovery in seguito a danneggiamento...

Mi scuso anzitutto per la domanda noiosa...

[Marco71]

...N.T.F.S o qualsiasi altro file system dotato di logging e journaling oltre che di una certa resilienza ai guasti ed alle corruzioni dati che il sistema ad allocazione dei files tabellare dato dalle F.A.T (a 32 o 16 bit) non può garantire.
Naturalmente Murphy docet ergo è sempre meglio non confidare sempre e solo sulla intrinseca affidabilità di un qualche sistema...potrebbe sempre "fallire".
Prima che anche Linux avesse supporto ubiquo alla lettura (ma anche alla scrittura) delle strutture dati del "New Technology File System" come sai, gli orrendi box esterni per hard disk venivano quasi sempre forniti "di fabbrica" con F.A.T.
Hai mai provato SpinRite 6 (è a pagamento ma costa poco) ?
Ciao hibone...

Marco71.

[hibone]

Originariamente inviato da Marco71

...N.T.F.S o qualsiasi altro file system dotato di logging e journaling oltre che di una certa resilienza ai guasti ed alle corruzioni dati che il sistema ad allocazione dei files tabellare dato dalle F.A.T (a 32 o 16 bit) non può garantire.
Naturalmente Murphy docet ergo è sempre meglio non confidare sempre e solo sulla intrinseca affidabilità di un qualche sistema...potrebbe sempre "fallire".
Prima che anche Linux avesse supporto ubiquo alla lettura (ma anche alla scrittura) delle strutture dati del "New Technology File System" come sai, gli orrendi box esterni per hard disk venivano quasi sempre forniti "di fabbrica" con F.A.T.
Hai mai provato SpinRite 6 (è a pagamento ma costa poco) ?
Ciao hibone...

Marco71.

Innanzitutto grazie per la risposta celere, riprendere in mano il Silberschatz mi dava la pelle d'oca , e grazie anche per il refresh...

Ho posto la questione perchè ricordavo che fosse migliore ma non ricordavo in cosa, e visto che devo consigliarlo a mio frate... Proprio adesso ho sottomano un Lacie uke: che guardacaso è formattato in Fat e quando si surriscalda va a ramengo: "periferica sconosciuta"

Per quanto riguarda Spin Rite non l'ho provato, mi son trovato molto bene con l'interfaccia di Rstudio e mi son abituato ad usare quello, ma a buttargli un occhio faccio presto.

Avevo menzionato salvation data è perchè sviluppa soluzioni "industriali" anche a livello hardware, per cui mi chiedevo se avessero capacità superiori rispetto ad altri software.


PS.
Come al solito è sempre un piacere leggerti..
Alla prossima...

[Marco71]

....hibone...il tuo avatar mi ricorda un certo test Voight-Kampff...di un libro e film che amo...

Marco71.

[gonZales]

Originariamente inviato da Marco71

...Hai mai provato SpinRite 6 (è a pagamento ma costa poco) ?

...scusa ma, ho cercato una guida in italiano per questo programma ma non sono riuscito a trovare niente...
Sai dirmi se c'è qualcosa, purtroppo con l'inglese sono in pessimi rapporti, grazie.

[Marco71]

...non mi viene in mente una locazione con un tutorial in lingua nostra madre...mi dispiace...
Thanks.

Marco71.

[almaxy]

Originariamente inviato da almaxy

Scusate la mia intromissione, anche io ho uno dei seguenti problemi:
ho un secondo HD da 250GB(dati) partizionato in due. Durante una copia di grossi files ad un tratto il disco mi è andato in errore diventendo inaccessibile.
Praticamente una partiz. dove avevo gorssi files non me la vede + e l'altra non mi riconosce + il file system, credo che si sia incasinato MBR.
Come posso risolvere il probl.? Ho provato con testdisk 6.9 diversissime volte ma nulla. Mi piacere ripristinare l'HD allo stato originale, se possibile, mi piacerebbe tentare.
Nei 212 GB(circa) ho quasi 160 GB di roba .....
Questa è la situazione:



Si vede l'immagine?
Altrimenti: http://xoomer.alice.it/pioantonio/immagini/Gest_PC.jpg

mi autoquoto ...

[MM]

Per Win 2000, nonostante le notizie che avevo e che tutti hanno, non è vero che con SP4 si risolva il problema
Per meglio precisare Win 2000 con SP4 è effettivamente in grado di gestire dischi superiori a 128 GiB, ma la feature non viene implementata in automatico e quindi è necessario inserire nel registro di configurazione (manualmente) l'instruzione che lo abilita a gestirli
Al momento non ho con me il link alla discussione con le istruzioni adeguate, ma la cerco...

[Marco71]

...come l'omonima trasmissione T.V.
Link Microsoft...
http://support.microsoft.com/kb/305098

Grazie.

Marco71.

[MM]

Ecco, bravo
Lo sapevo che tanto qualcuno se lo ricordava