Il perl non finisce mai di stupire per la sua flessibilità.
venerdì in una sera sola ho fatto questo:
http://naruteamplus.altervista.org/fr/
Il software è opensource.
Che ne pensi shishii? XD
Ciao
Il perl non finisce mai di stupire per la sua flessibilità.
venerdì in una sera sola ho fatto questo:
http://naruteamplus.altervista.org/fr/
Il software è opensource.
Che ne pensi shishii? XD
Ciao
Pero' se il file corrotto a dimensione diversa dall'originale non funza
Bisogna sistemare questa cosuccia![]()
Cmq puo' essere utile!
Non so come trovare i byte corrotti se la dim è differente, proprio per il meccanismo in cui opera.
FreeManX, cosa proponi per risolvere questo problema?
Forse si potrebbe partire con due hash dal primo e dall'ultimo byte, per poi ampliarsi e controllare gli ultimi due ed i primi due e poi...bo, ci devo pensare, sicuramente un algoritmo esisterà, non so però se è al mio livello.
Però solitamente quando avviene una corruzione, anche su irc, la DIM del file finale è la stessa dell'originale.
Ci vorrà un po' per pensarci.
Ciao...
Ciao,
complimenti per l'iniziativa, che speriamo completerai con la riparazione anche in presenza di dimensioni differenti.
In ogni caso avrai sicuramente imparato molto di più di chi si limita solo a chiedere.
Marco Allegretti
shishii@tiscalinet.it
Lang: PERL, PHP, SQL.
Linux user n° 268623 Fedora Core 10, Fedora Core 6, Debian Sarge on mips
Controllarlo a blocchi di n byte, se concidono ok altrimenti errore, questo dovrebbe essere valido sia per dimensioni uguali che diverse.Originariamente inviato da LordSaga640
Non so come trovare i byte corrotti se la dim è differente, proprio per il meccanismo in cui opera.
FreeManX, cosa proponi per risolvere questo problema?
Forse si potrebbe partire con due hash dal primo e dall'ultimo byte, per poi ampliarsi e controllare gli ultimi due ed i primi due e poi...bo, ci devo pensare, sicuramente un algoritmo esisterà, non so però se è al mio livello.
Però solitamente quando avviene una corruzione, anche su irc, la DIM del file finale è la stessa dell'originale.
Ci vorrà un po' per pensarci.
Ciao...
Pero' lo sparata cosi, non sono sicuro, prova!
Intanto: grazie shishii per i complimenti^^
Poi, FreeManX, stavo pensando anche alla soluzione che mi hai proposto, in effetti potrei verificare l'hash ogni MB e vedere se corrispondo e se poi non concidono di riscaricare il blocco da 1MB, però nel casi che in un punto mancassero dei byte, non ci troverebbe più una corrispondenza, ossia, non so più se i byte successivi nel file corrotti corrispondano realmente alla posizione attuale.
Ad esempio:
File originale: ABCDEFGHILMOPQRSTUVZ
File corrotto: ABCDEKGHIMONOPQRSTUVZ
Un pezzo è corrotto e manca anche un dato.
Il blocca originale A è uguale al blocco del file corrotto A? Si
B=B?
Continuerebbe così fino ad F e vede che son differenti e lo riscarica.
Poi arriva ad L e chiede se è uguale ad M del secondo file, dice di no e lo riscarica.
poi controlla M con O e son diversi, cioè, riscaricherebbe tutto il file dal byte corrotto in poi.
Ogni soluzione che mi viene in mente ha delle falle, e ammetto di non essere in grado di risolvere, almeno non oggi.
Penso che la soluzione si trovi solo pensando a quello che farei io avendo due editor esadecimali con i due file aperto e facendolo manualmente.
SOLUZIONE A:
-Crea un file di SWAP la dim del file originale
-Controllo se il primo blocco da 1MB è uguale all'originale, se è uguale lo salva nel file di SWAP.
-Controllo il blocco da un 1MB partendo dalla fine del file e se è corretto lo svalo nel file SWAP.
Azz...ora diventa difficile da spiegarlo, inizio a programmarlo, però è drastico, perchè se mancano dei dati sia nel punto iniziale che nella parte finale, lui mi riscarica tutto il file! @_@
Non ho altre soluzioni!
CIAO
Prova con una soluzione divide et impera!Originariamente inviato da LordSaga640
Intanto: grazie shishii per i complimenti^^
Poi, FreeManX, stavo pensando anche alla soluzione che mi hai proposto, in effetti potrei verificare l'hash ogni MB e vedere se corrispondo e se poi non concidono di riscaricare il blocco da 1MB, però nel casi che in un punto mancassero dei byte, non ci troverebbe più una corrispondenza, ossia, non so più se i byte successivi nel file corrotti corrispondano realmente alla posizione attuale.
Ad esempio:
File originale: ABCDEFGHILMOPQRSTUVZ
File corrotto: ABCDEKGHIMONOPQRSTUVZ
Un pezzo è corrotto e manca anche un dato.
Il blocca originale A è uguale al blocco del file corrotto A? Si
B=B?
Continuerebbe così fino ad F e vede che son differenti e lo riscarica.
Poi arriva ad L e chiede se è uguale ad M del secondo file, dice di no e lo riscarica.
poi controlla M con O e son diversi, cioè, riscaricherebbe tutto il file dal byte corrotto in poi.
Ogni soluzione che mi viene in mente ha delle falle, e ammetto di non essere in grado di risolvere, almeno non oggi.
Penso che la soluzione si trovi solo pensando a quello che farei io avendo due editor esadecimali con i due file aperto e facendolo manualmente.
SOLUZIONE A:
-Crea un file di SWAP la dim del file originale
-Controllo se il primo blocco da 1MB è uguale all'originale, se è uguale lo salva nel file di SWAP.
-Controllo il blocco da un 1MB partendo dalla fine del file e se è corretto lo svalo nel file SWAP.
Azz...ora diventa difficile da spiegarlo, inizio a programmarlo, però è drastico, perchè se mancano dei dati sia nel punto iniziale che nella parte finale, lui mi riscarica tutto il file! @_@
Non ho altre soluzioni!
CIAO(parolone grosso per dire) fai tipo ricerca binaria, potrebbe essere una soluzione.
Oppure per ovviare al problema detto da te del fatto del riscalare, quando trovi un inconcruenza, vedi lo stato del MB successivo, finche non lo trovi corretto, quando lo trovi, ti fermi e ripristini tutto dal punto del riscontro negativo a quello del positivo!
Penso che una soluzione del genere sia ottimale, anche xke ti permette di fare un restore di blocchi variabili con miglioria delle prestazioni, e non si blocchi fissi!
bye bye
Si, in effetti potrebbe essere una soluzione molto carina ^^.
Ora ci penso.
THX^^
ciao