View Full Version : [C/C++] dato 1 milione di file
la domanda non sarà affatto chiara ma ho il seguente problema che mi auguro qualcono abbia già trovato una soluzione.
Su un disco sono presenti 1 mione di file di diversa natura, tali file devono essere costantemente sincronizzati su un altro disco ma sorge il problema: come mi accorgo che i files sorgente sono "sani" cioè non corrotti ?
Potrebbe accadere infatti che ho i dati sul disco A corrottti, sul disco B sani ed ottengo due dischi con dati corrotti.
Purtropppo non ho conoscenze riguardo a questo genere di problematiche e nemmeno per quanto concerne il checksum dei dati: quale algoritmo adottare per mettersi al riparo da tali problematiche?
grazie
clockover
20-04-2013, 11:45
la domanda non sarà affatto chiara ma ho il seguente problema che mi auguro qualcono abbia già trovato una soluzione.
Su un disco sono presenti 1 mione di file di diversa natura, tali file devono essere costantemente sincronizzati su un altro disco ma sorge il problema: come mi accorgo che i files sorgente sono "sani" cioè non corrotti ?
Potrebbe accadere infatti che ho i dati sul disco A corrottti, sul disco B sani ed ottengo due dischi con dati corrotti.
Purtropppo non ho conoscenze riguardo a questo genere di problematiche e nemmeno per quanto concerne il checksum dei dati: quale algoritmo adottare per mettersi al riparo da tali problematiche?
grazie
Io penso che molto dipenda da cosa si intenda per "corrotto"
Io penso che molto dipenda da cosa si intenda per "corrotto"
un file di testo ad esempio, che presenta caratteri estranei lo considererei corrotto.
clockover
20-04-2013, 13:30
un file di testo ad esempio, che presenta caratteri estranei lo considererei corrotto.
Questa è una risposta che ti sei dato da solo. Devi stabilire un criterio per cui i tuoi files da sincronizzare possano dirsi regolari e non corrotti. In questo caso il file di testo. Per quanto riguarda altri files magari potresti dover controllare i metadati, ecc...
Il lavoro che vuoi fare tu comunque io, ma è solo una mia opinione e parlando di SO Linux, lo farei con uno script bash che magari utilizzi rsync.
Questa è una risposta che ti sei dato da solo. Devi stabilire un criterio per cui i tuoi files da sincronizzare possano dirsi regolari e non corrotti. In questo caso il file di testo. Per quanto riguarda altri files magari potresti dover controllare i metadati, ecc...
Il lavoro che vuoi fare tu comunque io, ma è solo una mia opinione e parlando di SO Linux, lo farei con uno script bash che magari utilizzi rsync.
la sincronizzazione è il meno dei mali, conosco diversi programmi per tale scopo, mi interessa di più tenere sotto controllo la qualità dei file prima di sincronizzare: c'è un modo?
Generi un hash per ciascuno dei file in un momento in cui sei sicuro che il file sia "corretto" (per esempio, subito dopo la generazione del file stesso???) e te lo salvi da qualche parte. Quando devi sincronizzare un certo file, rieffettui il calcolo dell'hash e lo confronti con quello che ti eri salvato (che è sicuramente giusto). Se coincidono puoi essere certo che il file non ha subito cambiamenti quindi è integro e può essere sincronizzato. Come algoritmo di hash puoi usare sha1 (anche md5 dovrebbe andare più che bene).
Non so se ho risposto alla tua domanda perchè non ho ben capito da quali situazioni esattamente ti vuoi parare...
Generi un hash per ciascuno dei file in un momento in cui sei sicuro che il file sia "corretto" (per esempio, subito dopo la generazione del file stesso???) e te lo salvi da qualche parte. Quando devi sincronizzare un certo file, rieffettui il calcolo dell'hash e lo confronti con quello che ti eri salvato (che è sicuramente giusto). Se coincidono puoi essere certo che il file non ha subito cambiamenti quindi è integro e può essere sincronizzato. Come algoritmo di hash puoi usare sha1 (anche md5 dovrebbe andare più che bene).
Non so se ho risposto alla tua domanda perchè non ho ben capito da quali situazioni esattamente ti vuoi parare...
a questo non ci avevo pensato. La situazione è quella tipica nella quale hai ad esempio due dischi ed in caso di problemi fai lavorare il secondo sempre che questo contenga file non corrotti. Il primo disco potrebbe avere cluster difettosi, oppure un virus ha cancellato o rovinato numerosi file e se sincronizzi il primo disco "malato" col secondo ti ritrovi due dischi malati.
clockover
20-04-2013, 16:20
Generi un hash per ciascuno dei file in un momento in cui sei sicuro che il file sia "corretto" (per esempio, subito dopo la generazione del file stesso???) e te lo salvi da qualche parte. Quando devi sincronizzare un certo file, rieffettui il calcolo dell'hash e lo confronti con quello che ti eri salvato (che è sicuramente giusto). Se coincidono puoi essere certo che il file non ha subito cambiamenti quindi è integro e può essere sincronizzato. Come algoritmo di hash puoi usare sha1 (anche md5 dovrebbe andare più che bene).
Non so se ho risposto alla tua domanda perchè non ho ben capito da quali situazioni esattamente ti vuoi parare...
Ma così facendo però hai solo la certezza che il file A nel disco 1 è uguale al file A nel disco 2. Se era solo questo il problema allora è banale. Quando effettui il download da un certo file da internet, solitamente di grandi dimensioni, ti mostrano il codice hash corrispondente per essere sicuri che il file scaricato non sia corrotto.
Io avevo capito che in caso di modifiche che portavano ad una inconsistenza di dati del file A nel disco 1, la sincronizzazione con il file A del disco 2 non avvenisse, dato che ovviamente in questo modo si avrebbero 2 file con dati non validi.
Ma così facendo però hai solo la certezza che il file A nel disco 1 è uguale al file A nel disco 2. Se era solo questo il problema allora è banale. Quando effettui il download da un certo file da internet, solitamente di grandi dimensioni, ti mostrano il codice hash corrispondente per essere sicuri che il file scaricato non sia corrotto.
Io avevo capito che in caso di modifiche che portavano ad una inconsistenza di dati del file A nel disco 1, la sincronizzazione con il file A del disco 2 non avvenisse, dato che ovviamente in questo modo si avrebbero 2 file con dati non validi.
ed hai capito bene. L'hash è solo un'idea che mi conservo, ma non mi tutela dal fatto che i file sul disco 1 siano validi.
Detta in altri termini: se decidi di fare un backup dei file presenti sul tuo disco in questo esatto istante, come fai a capire se tutti sono integri ?
Bisogna inventarsi qualcosa.
ed hai capito bene. L'hash è solo un'idea che mi conservo, ma non mi tutela dal fatto che i file sul disco 1 siano validi.
Detta in altri termini: se decidi di fare un backup dei file presenti sul tuo disco in questo esatto istante, come fai a capire se tutti sono integri ?
Bisogna inventarsi qualcosa.
La validità di un file è relativa alla tipologia stessa del file. Dovresti implementare un controllo specifico per ogni tipo/estensione.
Ma così facendo però hai solo la certezza che il file A nel disco 1 è uguale al file A nel disco 2. Se era solo questo il problema allora è banale. Quando effettui il download da un certo file da internet, solitamente di grandi dimensioni, ti mostrano il codice hash corrispondente per essere sicuri che il file scaricato non sia corrotto.
Io avevo capito che in caso di modifiche che portavano ad una inconsistenza di dati del file A nel disco 1, la sincronizzazione con il file A del disco 2 non avvenisse, dato che ovviamente in questo modo si avrebbero 2 file con dati non validi.
Non proprio, con la mia soluzione ti puoi accertare che non sono avvenute modifiche nel file e quindi lo puoi copiare/sincronizzare perchè quando ne hai fatto l'hash era "corretto", integro e quindi lo è anche adesso.
Altre forme di controllo non credo siano realisticamente possibili. Che ne so, metti che hai un mp3. In un certo momento, puoi verificare che il file sia corretto da un punto di vista del formato (header del formato per esempio) ma chi ti dice che non è stata cambiata una nota (almeno di sentirlo ovviamente :) )???
Non proprio, con la mia soluzione ti puoi accertare che non sono avvenute modifiche nel file e quindi lo puoi copiare/sincronizzare perchè quando ne hai fatto l'hash era "corretto", integro e quindi lo è anche adesso.
Altre forme di controllo non credo siano realisticamente possibili. Che ne so, metti che hai un mp3. In un certo momento, puoi verificare che il file sia corretto da un punto di vista del formato (header del formato per esempio) ma chi ti dice che non è stata cambiata una nota (almeno di sentirlo ovviamente :) )???
ma infatti è un inizio, ora si tratta di come usare tale soluzione in modo da limitare i danni al minimo.
Potrei creare l'hash di ogni file per tutto il disco, quindi di volta in volta crearlo per i file che cambiano e cioè quelli che sono stati modificati. Così facendo, prima di sincronizzare dovrei effettuare un controllo dell'hash file per file, determinare in percentuale quanti file sono ancora validi e quanti non lo sono ed in base a questi dati decidere se e come sincronizzare, il tutto in un tempo umano.
clockover
20-04-2013, 17:35
Non proprio, con la mia soluzione ti puoi accertare che non sono avvenute modifiche nel file e quindi lo puoi copiare/sincronizzare perchè quando ne hai fatto l'hash era "corretto", integro e quindi lo è anche adesso.
Altre forme di controllo non credo siano realisticamente possibili. Che ne so, metti che hai un mp3. In un certo momento, puoi verificare che il file sia corretto da un punto di vista del formato (header del formato per esempio) ma chi ti dice che non è stata cambiata una nota (almeno di sentirlo ovviamente :) )???
Un file MP3 non conosce note musicali, conosce solo sequenze di bit.
Inoltre se qualcosa in quell'MP3 è stato cambiato e funziona lo stesso allora il file è valido quindi non "corrotto".
L'hash è utile per questi scopi solo e soltanto se hai già un file valido.
Un file MP3 non conosce note musicali, conosce solo sequenze di bit.
Mi sembrava abbastanza ovvio che quando dicevo "una nota cambiata" intendevo uno dei bit che rappresentano i campioni audio... However...
Inoltre se qualcosa in quell'MP3 è stato cambiato e funziona lo stesso allora il file è valido quindi non "corrotto".
E' valido nel senso che lo puoi aprire senza che Media Player si lamenti, ma non rappresenta più l'informazione che era supposto contenere.
L'hash è utile per questi scopi solo e soltanto se hai già un file valido.
Concordo. Infatti nel mio primo post avevo scritto "Generi un hash per ciascuno dei file in un momento in cui sei sicuro che il file sia "corretto"". Quindi assumevo implicitamente che c'è un momento in cui puoi affermare con certezza che il file è giusto (per esempio quando lo crei... boh... dipende di che file si sta parlando).
Se volete che il controllo si limiti alla correttezza "sintattica" dei vari files allora bisogna prevedere tutti i formati che si intende backupare e trattarli uno per uno (parecchio noioso come lavoro)...
clockover
20-04-2013, 18:14
Su un disco sono presenti 1 mione di file di diversa natura, tali file devono essere costantemente sincronizzati su un altro disco ma sorge il problema: come mi accorgo che i files sorgente sono "sani" cioè non corrotti ?
Il fatto è che quando viene detto "costantemente sincronizzati" fa presupporre a files che subiscono dei mutamenti. In questo caso l'hash può essere utile solo a paragonare i due files già sincronizzati, e quindi una precauzione in più.
Quando parla di "corruzione" del file non si scappa: bisogna sapere con che tipo di dati si lavora (audio, video, testo, ecc...) e per ognuno di quelli conoscerne la ricetta.
Mi sembrava abbastanza ovvio che quando dicevo "una nota cambiata" intendevo uno dei bit che rappresentano i campioni audio... However...
Si certo figurati non pensavo che dicevi che c'erano le note li dentro. Quello che volevo dire io è che semplicemente un file MP3 modificato musicalmente non vuol dire "corrotto", ma semplicemente modificato. Mi sono spiegato male
Matt_245
20-04-2013, 18:24
Una sorta di fingerprint?
Il fatto è che quando viene detto "costantemente sincronizzati" fa presupporre a files che subiscono dei mutamenti. In questo caso l'hash può essere utile solo a paragonare i due files già sincronizzati, e quindi una precauzione in più.
Quando parla di "corruzione" del file non si scappa: bisogna sapere con che tipo di dati si lavora (audio, video, testo, ecc...) e per ognuno di quelli conoscerne la ricetta.
Si certo figurati non pensavo che dicevi che c'erano le note li dentro. Quello che volevo dire io è che semplicemente un file MP3 modificato musicalmente non vuol dire "corrotto", ma semplicemente modificato. Mi sono spiegato male
;) tutto chiaro, direi che le varie opinioni convergono. Adesso sta a misterx individuare l'opportuno set di funzionalità da implementare in base al risultato e alle proprietà che vuole garantire sui dati.
la domanda non sarà affatto chiara ma ho il seguente problema che mi auguro qualcono abbia già trovato una soluzione.
Su un disco sono presenti 1 mione di file di diversa natura, tali file devono essere costantemente sincronizzati su un altro disco ma sorge il problema: come mi accorgo che i files sorgente sono "sani" cioè non corrotti ?
Come gia' detto da altri, dipende da cosa si intende per corrotto.
Un file rovinato perche' dei settori sono difettosi e' una cosa diversa da un file rovinato perche' il programma che l'ha generato aveva un bug piuttosto che uno che si e' rovinato a causa di un virus.
La soluzione del checksum e' uno spostare il problema, perche' prima di fare il checksum devi essere sicuro che il contenuto e' corretto. In altri termini ti aiuta a verificare che il contenuto non e' stato alterato, ma non che fosse corretto fin da subito.
Io distinguerei il problema almeno su due livelli
- Corruzione a livello "fisico" (i.e. settori danneggiati, file system corrotto), causata dall'hardware o dal sistema operativo
- Corruzione a livello applicativo, causato dai programmi utente.
Il primo si risolve con una oculata scelta del sistema operativo e del supporto di monitoraggio. Ci sono file system (ZFS ad esempio) che per ogni blocco che scrivono su discono fanno un checksum che controllano ogni volta che lo rileggono; hai la certezza che se il S.O. ti dice che il dato e' stato salvato correttamente se si corrompe se ne accorge e, se ci piazzi pure un raid sotto, te lo corregge anche al volo.
Per il secondo dipende molto dal tipo di file. Se ti puoi ragionevolmente fidarti del programma che genera i file, e questi sono "write once" (cioe' non li vai a modificare una volta creati) allora l'idea del checksum torna comoda, perche' puoi legare la creazione del file con quella del checksum.
Il caso generale pero' e' difficile da risolvere, sia perche' i file li vai a modificare, sia perche' spesso un file "sbagliato" non e' tecnicamente corrotto (se ci sono pixel sbagliati in una immagine, l'immagine e' ancora di per se corretta).
La soluzione piu' pratica e' quella di non tenere solo la copia corrente dei dati (cosa che di solito con i backup non si fa mai), ma la maggior parte possibile di storico.
Per far di meglio, bisgona sapere l'utilizzo di quel milione di file...
Come gia' detto da altri, dipende da cosa si intende per corrotto.
Un file rovinato perche' dei settori sono difettosi e' una cosa diversa da un file rovinato perche' il programma che l'ha generato aveva un bug piuttosto che uno che si e' rovinato a causa di un virus.
La soluzione del checksum e' uno spostare il problema, perche' prima di fare il checksum devi essere sicuro che il contenuto e' corretto. In altri termini ti aiuta a verificare che il contenuto non e' stato alterato, ma non che fosse corretto fin da subito.
Io distinguerei il problema almeno su due livelli
- Corruzione a livello "fisico" (i.e. settori danneggiati, file system corrotto), causata dall'hardware o dal sistema operativo
- Corruzione a livello applicativo, causato dai programmi utente.
Il primo si risolve con una oculata scelta del sistema operativo e del supporto di monitoraggio. Ci sono file system (ZFS ad esempio) che per ogni blocco che scrivono su discono fanno un checksum che controllano ogni volta che lo rileggono; hai la certezza che se il S.O. ti dice che il dato e' stato salvato correttamente se si corrompe se ne accorge e, se ci piazzi pure un raid sotto, te lo corregge anche al volo.
Per il secondo dipende molto dal tipo di file. Se ti puoi ragionevolmente fidarti del programma che genera i file, e questi sono "write once" (cioe' non li vai a modificare una volta creati) allora l'idea del checksum torna comoda, perche' puoi legare la creazione del file con quella del checksum.
Il caso generale pero' e' difficile da risolvere, sia perche' i file li vai a modificare, sia perche' spesso un file "sbagliato" non e' tecnicamente corrotto (se ci sono pixel sbagliati in una immagine, l'immagine e' ancora di per se corretta).
La soluzione piu' pratica e' quella di non tenere solo la copia corrente dei dati (cosa che di solito con i backup non si fa mai), ma la maggior parte possibile di storico.
Per far di meglio, bisgona sapere l'utilizzo di quel milione di file...
ho scritto corrotto per identificare la casistica peggiore. Potrebbe entrare un virus che ti cancella molti file i quali servono ancora e risiedono, magari non aggiornati, sul secondo disco; a questo punto sincronizzi e i dati sono persi.
Lo stesso discorso lo hai anche quando effettui un backup; se i file sono conti e pochi il problema quasi non si pone, ma se i idati sono tanti e ignoti la soluzione forse non esiste.
tomminno
21-04-2013, 10:47
ho scritto corrotto per identificare la casistica peggiore. Potrebbe entrare un virus che ti cancella molti file i quali servono ancora e risiedono, magari non aggiornati, sul secondo disco; a questo punto sincronizzi e i dati sono persi.
Lo stesso discorso lo hai anche quando effettui un backup; se i file sono conti e pochi il problema quasi non si pone, ma se i idati sono tanti e ignoti la soluzione forse non esiste.
Mantenendo uno storico di backup sufficientemente lungo ti salvi da cancellazioni accidentali (ma ad oggi esistono ancora virus che cancellano file???).
Se ti preoccupi della corruzione fisica del file devi pensare di tenerli all'interno di un contenitore che consenta almeno il riconoscimento di questo stato (es .rar).
Ma dati tutti i sistemi che ci sono oggi, se l'hardware è realizzato con criterio non è un problema che mi porrei...
Quanto ad una eventuale modifica errata di un file a causa di bug del software che li scrive, credo che niente ti possa proteggere se non un'accurata test-suite del codice.
Ma hai un vero problema specifico da risolvere o stai semplicemente pensando a tutto quello che potrebbe succedere in linea teorica?
il problema è reale. MHO il backup non assicura affatto l'integrità dei dati, se ad esempio un virus inizia a cancellare dati al tempo t ed al tempo t+1 parte la sincronizzazione sei rovinato
il problema è reale. MHO il backup non assicura affatto l'integrità dei dati, se ad esempio un virus inizia a cancellare dati al tempo t ed al tempo t+1 parte la sincronizzazione sei rovinato
Il problema lo risolvi solo con una serie di backup che copre il tempo necessario affinchè tu ti accorga della corruzione/sparizione del dato.
Progettare un sistema capace di distinguere una modifica malevola ad un file da una legittima imho non è banale, e come già detto dovrebbe tener conto di criteri differenti per ogni tipologia di file.
ho scritto corrotto per identificare la casistica peggiore. Potrebbe entrare un virus che ti cancella molti file i quali servono ancora e risiedono, magari non aggiornati, sul secondo disco; a questo punto sincronizzi e i dati sono persi.
Lo stesso discorso lo hai anche quando effettui un backup; se i file sono conti e pochi il problema quasi non si pone, ma se i idati sono tanti e ignoti la soluzione forse non esiste.
La questione e' che in generale il computer non puo' sapere se un file e' stato cancellato perche' era da cancellare o perche' e' stato un virus o perche' ha sbagliato l'utente. L'unica soluzione pratica (a parte di casi specifici, come dicevo sopra) e' tenere uno storico, anche perche' il piu' delle volte in questi casi ci si accorge solo a posteriori che il file e' stato "rovinato". Se fai degli snapshot incrementali lo spazio occupato in piu' ad ogni backup e' proporzionale solo alla mole di dati modificati.
Tanto per fare un esempio sul mio NAS tengo uno snapshot ogni ora per le ultime 48 ore, uno ogni giorno per le ultime due settimane e uno al mese per gli ultimi 6 mesi. Lo spazio occupato non e' certo proporzionale al numero di snapshot.
il problema è reale. MHO il backup non assicura affatto l'integrità dei dati, se ad esempio un virus inizia a cancellare dati al tempo t ed al tempo t+1 parte la sincronizzazione sei rovinato
E si ritorna al problema iniziale. Come fai a sapere che il file e' stato cancellato da un virus e non da un utente che lo voleva cancellare ? Non lo sai.
E' per questo motivo che si fanno i backup e che si tiene uno storico. Con gli snapshot sull'unita' di backup riesci a tenere un ampio storico senza consumare un'infinita' di spazio.
La questione e' che in generale il computer non puo' sapere se un file e' stato cancellato perche' era da cancellare o perche' e' stato un virus o perche' ha sbagliato l'utente. L'unica soluzione pratica (a parte di casi specifici, come dicevo sopra) e' tenere uno storico, anche perche' il piu' delle volte in questi casi ci si accorge solo a posteriori che il file e' stato "rovinato". Se fai degli snapshot incrementali lo spazio occupato in piu' ad ogni backup e' proporzionale solo alla mole di dati modificati.
Tanto per fare un esempio sul mio NAS tengo uno snapshot ogni ora per le ultime 48 ore, uno ogni giorno per le ultime due settimane e uno al mese per gli ultimi 6 mesi. Lo spazio occupato non e' certo proporzionale al numero di snapshot.
cosa usi per fare gli snapshot?
tomminno
22-04-2013, 09:21
il problema è reale. MHO il backup non assicura affatto l'integrità dei dati, se ad esempio un virus inizia a cancellare dati al tempo t ed al tempo t+1 parte la sincronizzazione sei rovinato
Sincronizzazione e backup sono 2 cose diverse.
In quanto te avrai il backup al tempo t-1 quindi il file te lo ritrovi sul backup.
Sincronizzazione e backup sono 2 cose diverse.
In quanto te avrai il backup al tempo t-1 quindi il file te lo ritrovi sul backup.
ma il mio messaggio intendeva dire che il backup non sempre ti mette al sicuro.
Hai due disci A e B che sincronizzi ad esempio ogni ora; al tempo t un virus elimina molti files e nessuno se ne accorge; al tempo t+1 parte la sincronizzazione dei dischi A e B e ti ritrovi con due dischi quasi inutili. Al tempo t+2 parte anche il backup e ti ritrovi anche il backup quasi inutile.
ma il mio messaggio intendeva dire che il backup non sempre ti mette al sicuro.
Hai due disci A e B che sincronizzi ad esempio ogni ora; al tempo t un virus elimina molti files e nessuno se ne accorge; al tempo t+1 parte la sincronizzazione dei dischi A e B e ti ritrovi con due dischi quasi inutili. Al tempo t+2 parte anche il backup e ti ritrovi anche il backup quasi inutile.
E si ritorna all'utilità del backup a t-1.
Nel caso, si può introdurre della logica nel backup. Esempio, eseguire un delta tra t e t-1 e notificare modifiche a più del 10% dei file.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.