[C/C++] dato 1 milione di file

[misterx]

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]

Originariamente inviato da misterx

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"

[misterx]

Originariamente inviato da clockover

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]

Originariamente inviato da misterx

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.

[misterx]

Originariamente inviato da clockover

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?

[Mettiu_]

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...

[misterx]

Originariamente inviato da Mettiu_

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]

Originariamente inviato da Mettiu_

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.

[misterx]

Originariamente inviato da clockover

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.

[GByTe87]

Originariamente inviato da misterx

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.

[Mettiu_]

Originariamente inviato da clockover

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 )???

[misterx]

Originariamente inviato da Mettiu_

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]

Originariamente inviato da Mettiu_

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.

[Mettiu_]

Originariamente inviato da clockover

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...

Originariamente inviato da clockover

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.

Originariamente inviato da clockover

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]

Originariamente inviato da misterx

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.

Originariamente inviato da Mettiu_

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]

Una sorta di fingerprint?

[Mettiu_]

Originariamente inviato da clockover

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.

[marco.r]

Originariamente inviato da misterx

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...

[misterx]

Originariamente inviato da marco.r

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]

Originariamente inviato da misterx

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?