Scusa per gli eccessivi messaggi..
Non sprecare i byte, l'UMTS costa oro..
Quindi mi chiedo..cosa suggeriamo a Nighthawk???
Non sprecare i byte, l'UMTS costa oro..
Quindi mi chiedo..cosa suggeriamo a Nighthawk???
Aiuto per data recovery
- Autore discussione Nighthawk
- Data d'inizio
se il problema e' solo di MBR e per caso avere il cd di ubuntu v.7.04 avviate il pc con quello (assomiglia tanto a xp) poi dal menu comandi, se ricordo bene, eseguite il comando ntfsrepair ed il disco di xp riparte come lo avevate lasciato ....salvate tutto e occhio che quano si comincia a perdere la traccia 0 dell' hd una volta e' sicuro che la si riperdera' ancora... il disco non e' piu' affidabile al 100%
non e' una prova a casccio! l' ho gia' usata diverse volte su HD con bootrecord 'perso' secondo xp e mi ha sempre ripristinato il disco cosi' come era prima.
del resto chi interroghi per sapere cos'e' successo?
e se e' l' MBR danneggiato come lo ripari senza perdere nulla?
c'e' un vecchio metodo per non perdere nulla ma da molti e' ignorato o considerato una palla
...il BACKUP ....perdi un po' di tempo ma non perdi i dati !!!!
del resto chi interroghi per sapere cos'e' successo?
e se e' l' MBR danneggiato come lo ripari senza perdere nulla?
c'e' un vecchio metodo per non perdere nulla ma da molti e' ignorato o considerato una palla
...il BACKUP ....perdi un po' di tempo ma non perdi i dati !!!!
Interrogo l'hard-di. Così quando correggo l'MBR (che poi non è l'MBR, ma quasi certamente la partition table) è sicuro che tutto funzionerà al 100%.can Bus":1zpdni2c ha detto:
Col diskedit, o col dd, hex e vi.
ci sarebbe molto da dire sui backup, su come si facciano. Non è per nulla così semplice come potrebbe sembrare.
Tanto ormai è andato.. nel senso che erano dati che potevo perdere, ho riformattato a basso livello!!
Però questi consigli potrebbero tornarmi utili visto che prima o poi me lo aspetto un altro scherzetto del genere!! :asd)
@Internik: ma l'hex è in linguaggio assembler??
Però questi consigli potrebbero tornarmi utili visto che prima o poi me lo aspetto un altro scherzetto del genere!! :asd)
@Internik: ma l'hex è in linguaggio assembler??
Che spreco! Al 99.99999999999999999999999999999999999999999999999999999999999999999999999% era perfettamente recuperabile tutto quanto :shrug03)Nighthawk":1wdo2nxe ha detto:
Eppoi sarei proprio curioso di sapere come hai fatto a "riformattare a basso livello" qualcosa, perchè io non ne sarei capace
[è un modo gentile per dire che NON ESISTONO FORMATTAZIONI A BASSO LIVELLO, OGGI]Usa dvdsig o fsum prima delle copie, e falle e poi verificale
è un programma che converte file binari in dump esadecimali e viceversa (su linux). Su DOS è un editor esadecimale (PS ne esisteranno a centinaia di omonimi)
Che c'entra l'assember?
Si ma ho detto che quei dati non erano importantissimi.. tra l'altro li ho ritrovati su un cd che avevo fatto tempo fa (non aggiornatissimi ma gia tutto ok)Internik":2ey7i0r0 ha detto:
So bene che non esistono più formattazioni a basso livello.. era per dire che ho formattato usando quelle utility che rilasciava la Maxtor per la formattazione, quindi (tecnicamente) non ci sarebbe piu modo di recuperare i dati!!
Ti spieghi meglio per piacere?? Non li conosco.. a cosa servono?? :confusbig)
Non lo so.. se l'avessi saputo non l'avrei nemmeno chiesto!! Grazie!!! :OK)
E perchè mai lo hai fatto? Speravi di ottenere qualcosa di diverso rispetto ad una formattazione "normale"?Nighthawk":3pj9fv4x ha detto:
La cosa più furba da fare per un backup sicuro è quello di avere la certezza che i file originali siano identici ai file copiati, ed inoltre che i file copiati sono "giusti" anche letti su un altro computer.
Questo per evitare, ad esempio, che un banco RAM difettoso ti faccia corrompere un film che salvi su un disco USB; magari tu confronti il file sul disco USB con quello dell'hd e (pensi) di essere sicuro al 100% che siano uguali.
Invece, magari per sfiga massima, il file viene proprio ricaricato in quella cella difettosa (per la cache), e la verifica ti dà risultato positivo, anche se in realtà il file è copiato male (che culo, eh? :asd) ... capita... capita anche ben di peggio!)
Il modo "furbo" è quindi quello di calcolare la firma hash dei file, copiarli, e verificare la firma su un altro computer.
Cos'è la firma hash? E' una sorta di codice di controllo che dato un file fornisce la sua "firma digitale", un po' come il CIN dei conti correnti (hai presente come funziona?)
Esistono numerosissime funzioni hash (dalla storica CRC, all'usatissima MD5, ad SHA1, SHA256 etc).
Anche qui si potrebbe approfondire per spiegare perchè certe funzioni (tipo MD5) non sono "sicurissime", e perfino SHA1 non lo è.
Però, ai fini pratici, anche MD5 va benissimo per uso casareccio.
In pratica scarichi uno dei 1000 programmi (dvdsig ha interfaccia grafica, fsum testo) che applicherai sui file da COPIARE per poi memorizzare le firme calcolate in un opportuno file (chessè, firme.txt).
POI copierai i file (ad es. su DVD o quello che vuoi)
POI andrai su un altro PC e lì RICALCOLERAI le firme, per poi confrontarle con quelle salvate, per essere sicuro che la copia sia conforme.
Con fsum puoi fare qualcosa tipo
fsum -r -sha256 * > \controllo.fsum
e poi (dopo aver copiato)
fsum -jf -c \controllo.fsum
Con dvdsig è tutto più semplice, anche se devi operare a mano; attenzione che ti darà messaggi d'errore per file a lunghezza 0
[/quote]Bhè non c'è mica nulla di male...
in due parole: il codice esadecimale altro non è un una base di numerazione che, invece di usare i numeri tra 0 e 9, ne usa 16 (0-9, A=10; B=11;C=12;D=13;E=14;F=15).
E' solo un modo diverso per scrivere il medesimo numero.
Ad esempio 80 esadecimale = 128 decimale, o FF esadecimale= 255 decimale.
I c.d. "dump esadecimali" altro non sono che sequenze numeriche che possono corrispondere a qualsiasi cosa.
Ad es.
00 BC D3 A5 altro non è che la sequenza numerica
00 188 211 165 (in decimale).
Il "perchè" si usa dipende da motivi storici e dal fatto che rappresenta in forma più compatta (max 2 caratteri) numeri esprimibili con 8 bit binari (ossia tra 0 e 255).
Un dump esadecimale, semplicemente, prende un file e fa qualcosa tipo questo
In pratica per modificare un settore del disco (il primo), in assenza di strumenti più "comodi", lo si può leggere (con dd) in un file da 512 byte, trasformarlo (con hex o programmi simili) in un file DI TESTO contenente i relativi codici esadecimali, modificarlo col vi (in pratica "col notepad"), riconvertirlo in formato binario, e poi riscriverlo su disco. :OK)
PS spesso c'è l'associazione tra "assembler" e codici esadecimali, ma è del tutto errata, in quanto l'assembler è un linguaggio di programmazione facilmente trasformabile nel codice macchina (eseguibile) di un certo microprocessore.
Un esempio di programma assembler può essere questo
;************************************************************************
;* BOOTSTRAP macchina virtuale CSC1. Gruppo Sistemi 7 *
;************************************************************************
; Versione 1.0 - 23.04.93
; Bootstrap con controllo sulla lunghezza del programma inserito
ORG FF00 ; Indirizzo BOOTSTRAP
IN ; Byte alto START
STORE MYSTORE+1
STORE SALTA+1
IN ; Byte basso START
STORE MYSTORE+2
STORE SALTA+2
IN ; Byte alto lunghezza
STORE QUANTI
IN ; Byte basso lunghezza
STORE QUANTI+1
LOADADD MYSTORE+1 ; Somma START a lunghezza
ADDADD QUANTI
STOREADD QUANTI ; memorizza fine
LOOP IN ; richiedi byte programma
MYSTORE STORE H0000 ; memorizzalo
LOADADD MYSTORE+1 ; incrementa indirizzo
ADDADD UNO ; prossimo byte
STOREADD MYSTORE+1
LOAD MYSTORE+1 ; il byte alto della fine
SUB QUANTI ; Š uguale a quello
BRZERO FORSEUGUALI ; corrente ? si ->forseuguali
BRANCH LOOP ; no -> continua
FORSEUGUALI LOAD MYSTORE+2 ; confronta byte basso
SUB QUANTI+1
BRZERO SALTA ; uguale ? -> salta
BRANCH LOOP ; no -> continua
SALTA BRANCH H0000 ; lancia programma utente
UNO DCB 0001 ; costante additiva
QUANTI DCB 0000 ; indirizzo finale
una volta assemblato=convertito in codice macchina, diventa un file composto da una sequenza di byte, e basta.
Se li esprimi in esadecimale hai un dump, tipo questo
FF00
0D
02
FF
21
02
FF
45
0D
02
FF
22
02
FF
46
0D
02
FF
49
0D
02
FF
4A
03
FF
21
06
FF
49
04
FF
49
0D
02
00
00
03
FF
21
06
FF
47
04
FF
21
01
FF
21
07
FF
49
09
FF
38
08
FF
1F
01
FF
22
07
FF
4A
09
FF
44
08
FF
1F
08
00
00
00
01
00
00
Se sei curioso potrai osservare che le ultime direttive
UNO DCB 0001 ; costante additiva
QUANTI DCB 0000 ; indirizzo finale
vengono trasformate negli ultimi 4 byte
00
01
00
00
Se ci fosse stato, in fondo, un DCB A0B3 avresti gli ultimi 3 byte con scritto
A0
B3
(-anche se qui si aprirebbe il discorso big-little endian etc. etc).
:?: mamma mia Internik.. grazie per la spiegazione!!
Ti ho chiesto se fosse in assembler perche è un linguaggio di programmazione che per motivi di tempo non ho potuto approfondire al contrario di altri (come il Basic, VB o C++).
Però sembra interessante...
Ti ho chiesto se fosse in assembler perche è un linguaggio di programmazione che per motivi di tempo non ho potuto approfondire al contrario di altri (come il Basic, VB o C++).
Però sembra interessante...
In realtà assembler non è "un" linguaggio di programmazione, ma è tipicamente (anche se ne esistono parecchi non approfondisco) IL linguaggio di un certo microprocessore.Nighthawk":jqux5rqe ha detto::?: mamma mia Internik.. grazie per la spiegazione!!
Ti ho chiesto se fosse in assembler perche è un linguaggio di programmazione che per motivi di tempo non ho potuto approfondire al contrario di altri (come il Basic, VB o C++).
Però sembra interessante...
l'assember X86 è del tutto diverso da quello di un powerpc o di un motorola 68K etc.
Come si fa a "vivere" senza conoscere l'assembler del computer che si usa? E magari anche delle altre architetture principali? è la base di tutto!
:OK)
Quindi non c'è un solo tipo di linguaggio assembler, unico per tutti i uP??
se ho capito bene il linguaggio macchina di un X86 è diverso da un altro uP!!
Allora non è neanche esatto definirlo un linguaggio di programmazione e paragonarlo ai programmi di prima (VB, C++, Pascal..) ??
se ho capito bene il linguaggio macchina di un X86 è diverso da un altro uP!!
Allora non è neanche esatto definirlo un linguaggio di programmazione e paragonarlo ai programmi di prima (VB, C++, Pascal..) ??
hai perfettamente centrato :nod)Nighthawk":1v6ifu5i ha detto:
Tra l'altro, all'interno di un SINGOLO processore, possono esister PIU' assembler diversi che generano lo stesso codice macchina.
Tipicamente ci si riferisce (al 99%) all'assembler Intel (nel caso X86), ma tempo fa, ad esempio (tipo 10-15 anni) Borland faceva il suo Turbo Assembler leggermente diverso (ovviamente migliore) di quello "standard".
Le differenze principali non sono tanto negli op-code, quanto nelle direttive (tipicamente per i dati statici e lo stack)