Il copia-incolla di Windows è attendibile? Mi sa proprio di no...

havanalocobandicoot · 30-06-2008, 19:21

Ho copiato un file da quasi 5 GiB da un hard disk USB ad un altro. Dopo la copia, secondo Windows senza errori, ho fatto un controllo CRC con CD Check e un MD5: hash diversi.
E' un file video registrato dalla TV, e aprendolo si vede, le dimensioni sono le stesse, eppure l'MD5 e il CRC sono diversi.
Ho provato varie volte, e il risultato sono sempre hash diversi.
Provato invece 1 volta da hard disk USB ad hard disk interno SATA: hash MD5 corretto.

Com'è possibile tutto ciò?
Il file non viene copiato bene o cosa?
Ho sentito parlare qualche volta di controllo errori. C'entra qualcosa?

AnonimoVeneziano · 30-06-2008, 19:24

Che filesystem hai usato per il trasferimento?

Se il filesystem di partenza era un NTFS e quello di arrivo era un FAT32 è una cosa normale, visto che FAT32 non supporta file di dimensione superiore ai 4 GB, quindi , teoricamente, quello da 5 GB viene troncato.

Ciao

havanalocobandicoot · 30-06-2008, 19:32

Quote:

Originariamente inviato da AnonimoVeneziano

Che filesystem hai usato per il trasferimento?

Se il filesystem di partenza era un NTFS e quello di arrivo era un FAT32 è una cosa normale, visto che FAT32 non supporta file di dimensione superiore ai 4 GB, quindi , teoricamente, quello da 5 GB viene troncato.

Ciao

Sospettavo che a qualcuno sarebbe venuto il dubbio, e ho sbagliato io ad omettere questa informazione. Si tratta di NTFS. Niente FAT.

CRL · 01-07-2008, 01:22

Sta cosa è strana, ma non so bene come venga calcolato l'hash. Potrebbe avere a che fare con la cluster size, o qualcosa del genere? Magari l'hash è calcolato a blocchi, e i due dischi non hanno la stessa struttura dati di base.

Puoi provare a formattare uno dei due, o una nuova partizione apposita, con dimensione cluster diversa, e fare qualche prova.

- CRL -

havanalocobandicoot · 01-07-2008, 01:35

Quote:

Originariamente inviato da CRL

Sta cosa è strana, ma non so bene come venga calcolato l'hash. Potrebbe avere a che fare con la cluster size, o qualcosa del genere? Magari l'hash è calcolato a blocchi, e i due dischi non hanno la stessa struttura dati di base.

Puoi provare a formattare uno dei due, o una nuova partizione apposita, con dimensione cluster diversa, e fare qualche prova.

- CRL -

I dischi sono entrambi in NTFS a 4k di cluster size.
Comunque ho messo l'hard disk in un altro box, ci ho copiato dentro lo stesso file di prima, e mi ha dato hash MD5 corretto (come quello di origine). Stupidi cavetti cinesi da 10 euro!!

Un'altra volta avevo avuto problemi del genere con un controller IDE su slot PCI: molti archivi RAR all'interno erano "magicamente" corrotti.

Però non è giusta sta cosa... uno copia tranquillo un file, Windows dice che è tutto ok... e se uno non fa un hash MD5 o CRC non si accorge che il file che ha copiato è CORROTTO! Che schifo!!

Che ci vorrebbe da parte di Microsoft ad integrare un controllo degli errori nel copia e incolla?? Magari attivabile da parte dell'utente se proprio non vogliono integrarlo direttamente... Mica posso mettermi a fare l'hash di ogni file che copio!!

Ma scusate... è o non è una cosa fondamentale l'integrità dei dati??

Le ram ECC hanno un controllo degli errori di questo tipo? Con quelle si potrebbe vedere se un file viene corrotto durante la copia? Se è così le prendo al volo... quanto viene un kit DDR2 da 2 GB?

CRL · 01-07-2008, 01:41

Beh, cavolo, sta cosa non dovrebbe succedere.

Vediamo se qualcuno più preparato interviene a dirci qualcosa, il controllo CRC c'è già sul cavo, se no chi sa cosa verrebbe copiato, ci sono un mare di errori e ritrasmissioni in tutte le operazioni di copia, non capisco perchè in questo caso non vengano rilevate.

La ECC costa cifre spropositate, e comunque non credo risolverebbe, perchè in questo caso è il box che deve rispondere e restituire il CRC del pacchetto ricevuto, e se è diverso da quelo spedito il dato viene ritrasmesso.

- CRL -

Link Wolf · 01-07-2008, 02:08

Bhe ragazzi dopo che mi avete sollevato questo dubbio atroce mi son rimboccato le maniche ed ho fatto qualche prova:

Da disco singolo NTFS 4K cluster a RAID0 NTFS 4K cluster, tutto ok:

Da disco singolo NTFS 4K cluster a Ramdrive FAT32 ??K cluster, tutto ok

Altri test al prossimo edit...

EDIT:

File copiato più volte da: NTFS 4K cluster a pendrive FAT a ramdrive NTFS 512 byte e poi verificato checksum MD5 tra file del primo disco e quello dell'ultimo:

havanalocobandicoot · 01-07-2008, 02:59

Hai fatto la prova con file piccoli o anche molto grossi? Perché anche col controller schifoso cinese io ho copiato decine di GiB senza errori di hash... E poi il problema penso sia proprio là, e che se copiassi un file da 10 GB dal primo hard disk interno al secondo, e poi prendessi questo e lo ricopiassi sul primo, e così via altre 100 volte, probabilemente alla fine il file avrebbe hash corretto, proprio perché magari una scheda madre lavora meglio di uno schifo di cavetto cinese. Però quando il controller non lavora bene, Windows me lo deve dire... inutile che devo fare io un controllo hash su ogni file che copio... dai...

Link Wolf · 01-07-2008, 03:07

Quote:

Originariamente inviato da havanalocobandicoot

Hai fatto la prova con file piccoli o anche molto grossi? Perché anche col controller schifoso cinese io ho copiato decine di GiB senza errori di hash... E poi il problema penso sia proprio là, e che se copiassi un file da 10 GB dal primo hard disk interno al secondo, e poi prendessi questo e lo ricopiassi sul primo, e così via altre 100 volte, probabilemente alla fine il file avrebbe hash corretto, proprio perché magari una scheda madre lavora meglio di uno schifo di cavetto cinese. Però quando il controller non lavora bene, Windows me lo deve dire... inutile che devo fare io un controllo hash su ogni file che copio... dai...

Ho provato da HD ad HD un file di 4.51 GB, e poi tutte le prove che vedi sopra sono fatte con un file di 178 mega

.

Ti quoto in toto per quanto riguada il windows taciturno

Fui anche io vittima di una corruzione massiccia di dati: Avevo un sistema AMD con Scheda madre basata sul VIA ApolloKT133A col SB 686B. Succedeva che copiando i file dal canale primario IDE Master a quello secondario IDE Master li corrompeva nell'80% dei casi nonostante la copia riuscisse in maniera perfetta secondo XP, assurdo

...

Intanto sto provando con un file di 20 GB a fargli il checksum dopo averlo "sbattuto"(

) su vari dischi

Eccolo

havanalocobandicoot · 14-07-2008, 01:44

up

Pinucciotronic · 14-07-2008, 10:47

Ciao,
solo per segnalare che anche io ho riscontrato problemi similari.
Ho una catena RAID dove il copia/incolla non ha MAI prodotto errori, mentre una diversa catena RAID SATA, produce talora errori sopra il giga.
Mi fido talmente poco dei processi generici di windows, che per i trasferimenti uso dei software specifici (trovo valido, "viceversa" con controlli interni.
Concordo assolutamente con te; se si tratta di un problema software di windows, sarebbe davvero una pessima cosa.

havanalocobandicoot · 14-07-2008, 13:26

Quote:

Originariamente inviato da Pinucciotronic

Ho una catena RAID dove il copia/incolla non ha MAI prodotto errori, mentre una diversa catena RAID SATA, produce talora errori sopra il giga.

Quali sono le differenze tra questi due raid? Come ti sei accorto degli errori? Errori di che tipo?

Quote:

Originariamente inviato da Pinucciotronic

Mi fido talmente poco dei processi generici di windows, che per i trasferimenti uso dei software specifici (trovo valido, "viceversa" con controlli interni.

Cosa intendi per processi generici di Windows? Il software Viceversa cosa ti permette di fare?

Quote:

Originariamente inviato da Pinucciotronic

Concordo assolutamente con te; se si tratta di un problema software di windows, sarebbe davvero una pessima cosa.

Non mi pare di aver mai detto che si tratta di un problema software di Windows, ma ho imputato il problema ai controller. Ho invece criticato Windows per non avere dei controlli che informano e correggono gli errori che questi controller fanno.

Pinucciotronic · 14-07-2008, 14:34

Quote:

Originariamente inviato da havanalocobandicoot

Quali sono le differenze tra questi due raid? Come ti sei accorto degli errori? Errori di che tipo?

Cosa intendi per processi generici di Windows? Il software Viceversa cosa ti permette di fare?

Non mi pare di aver mai detto che si tratta di un problema software di Windows, ma ho imputato il problema ai controller. Ho invece criticato Windows per non avere dei controlli che informano e correggono gli errori che questi controller fanno.

Azz...siamo davanti al Pubblico Ministero!

Punto 1 :
Ho rilevato errori diretti, riscontrati via osservazione diretta (file avi, che mostravano errori assenti sul file d'origine) ed attraverso l'osservazione di difformità, tra originale e copia, sul peso byte dei file stessi.

Punto 2:
Per processo generico di windows, applicato a questo caso, intendo il riscontro che il SO dovrebbe fornire al termine di un processo di copia/incolla...se la copia è difforme dall'originale, il SO dovrebbe istantaneamente avvertire l'utente, o meglio ancora, annullare il processo.
"Viceversa" nasce per il backup, ma i suoi controlli software (2 tecnologie), fanno in modo che un file copiato e trasferito altrove sia esattamente uguale alla versione originale (proprietà specifiche del file incluse).

Punto 3:
Se il controller non funziona, l'unica è avere fiducia nel SO. Se Windows rimane silenzioso, ti offre un pessimo servizio (un errore bello e buono).In buona sostanza il controller da dieci euro è padrone di lavorare male, ma il tuo SO dovrebbe fare il suo lavoro di supervisore.

Spero di avere risposto bene.

havanalocobandicoot · 14-07-2008, 22:43

Quote:

Originariamente inviato da Pinucciotronic

Azz...siamo davanti al Pubblico Ministero!

...

Spero di avere risposto bene.

No, non lo hai fatto. Non ti offendere, ma a mio avviso non ti esprimi bene.
Non sono un P.M. ma ho il diritto di chiedere. Siamo su un forum, dove si discute. Mi sono posto dei quesiti su quanto hai detto e ho chiesto. Non vedo stranezze.
Domandare è lecito, rispondere è cortesia.

Quote:

Originariamente inviato da Pinucciotronic

Punto 1 :
Ho rilevato errori diretti, riscontrati via osservazione diretta (file avi, che mostravano errori assenti sul file d'origine)

Continui a non parlare di questi errori.

Quote:

Originariamente inviato da Pinucciotronic

"Viceversa" nasce per il backup, ma i suoi controlli software (2 tecnologie), fanno in modo che un file copiato e trasferito altrove sia esattamente uguale alla versione originale (proprietà specifiche del file incluse).

Proprietà specifiche in che senso?

Quote:

Originariamente inviato da Pinucciotronic

Punto 3:
Se il controller non funziona, l'unica è avere fiducia nel SO. Se Windows rimane silenzioso, ti offre un pessimo servizio (un errore bello e buono).In buona sostanza il controller da dieci euro è padrone di lavorare male, ma il tuo SO dovrebbe fare il suo lavoro di supervisore.

Giustissimo. Continuo a non capire il significato si "se si tratta di un problema software di windows, sarebbe davvero una pessima cosa".
Curioso... ma dal tuo nick e da come ti esprimi mi ricordi una mia conoscenza.

Pinucciotronic · 14-07-2008, 22:49

Vai a farti benedire.

CRL · 14-07-2008, 22:52

Quote:

Originariamente inviato da Pinucciotronic

Vai a farti benedire.

Prego?

Cerchiamo di non scadere per cortesia, se avete vicende pregresse ci sono i pvt, grazie. Cartellino giallo.

- CRL -

Pinucciotronic · 14-07-2008, 22:57

Grazie per il cartellino giallo...l'ho speso bene e e di cuore.

havanalocobandicoot · 19-07-2008, 03:57

up

19-07-2008, 09:18

Iscritto e interessato

Ogni giorno copio/sposto tanti di quei gb che non avete neanche idea.
Questo thread mi ha fatto cadere le braccia

DVD_QTDVS · 19-07-2008, 09:53

Per gli utenti più evoluti, i nodi iniziano ad arrivare al pettine,
alla faccia di chi diceva, il nuovo è meglio, perchè ti fai tutte queste seghe mentali.. ecc. ecc.

La verità è che le normali ddr e ddr2 sono delle memorie da videogame,
e così pure alcuni sistemi operativi, il cui unico scopo principlae è difendere il DRM
e permettere l'accesso ai dati da parte della software house, virus e spyware,
così da far girare anche il mercato di altri prodotti softuare..

Ok, detto questo passiamo alla parte pratica...

Prima di tutto è necessario controllare la Ram con memtest86,
senza overclock, xchè l'overclock di bus può gengerare errori.
Anche un solo errore può compromettere il file salvato.

Se la ram è ok si passa ad uno scan dei settori dell' hard disk con HdTune,
e sarebbe pure opportuno controllare i parametri smart.
Questo controllo si può eseguire pure con le Seatools, preferibilmente a disco vuoto.

Poi c'è da considerare il fatto che il sistema NTSF comprime alcuni file o parti di file,
e questo è molto pericoloso x l'integrità dei dati, perchè quando il file viene copiato,
viene anche elaborato, e quindi la possibilità di errore viene elevata di potenza N..

Per i file corrotti io proverei a fare un confronto bit a bit per vedere quali parti
risultano diverse, se pochi bit oppure interi cluster.

D'altra parte se i computer della classe workstation o mainframe, adottano
memoria ECC, e sistema operativo Unix con md5 ci sarà pure un perchè..

30-06-2008, 19:21	#1
havanalocobandicoot Senior Member Iscritto dal: Jun 2005 Messaggi: 4057	Il copia-incolla di Windows è attendibile? Mi sa proprio di no... Ho copiato un file da quasi 5 GiB da un hard disk USB ad un altro. Dopo la copia, secondo Windows senza errori, ho fatto un controllo CRC con CD Check e un MD5: hash diversi. E' un file video registrato dalla TV, e aprendolo si vede, le dimensioni sono le stesse, eppure l'MD5 e il CRC sono diversi. Ho provato varie volte, e il risultato sono sempre hash diversi. Provato invece 1 volta da hard disk USB ad hard disk interno SATA: hash MD5 corretto. Com'è possibile tutto ciò? Il file non viene copiato bene o cosa? Ho sentito parlare qualche volta di controllo errori. C'entra qualcosa? __________________ >>>>> Benchmark di velocità in lettura di tutte le periferiche di memorizzazione <<<<< OCCHIO A VISTA E A WINDOWS 7! - HANNO DECISO DI NON FIDARSI DI TE! GUARDA IL VIDEO *Uno dei difetti dell'open source è la troppa libertà, e, ad oggi, il decentramento delle energie. El pueblo unido jamás será vencido!*

30-06-2008, 19:24	#2
AnonimoVeneziano Senior Member Iscritto dal: Aug 2001 Città: San Francisco, CA, USA Messaggi: 13827	Che filesystem hai usato per il trasferimento? Se il filesystem di partenza era un NTFS e quello di arrivo era un FAT32 è una cosa normale, visto che FAT32 non supporta file di dimensione superiore ai 4 GB, quindi , teoricamente, quello da 5 GB viene troncato. Ciao __________________ GPU Compiler Engineer

01-07-2008, 01:22	#4
CRL Senior Member Iscritto dal: Jun 2004 Città: London, UK Messaggi: 10708	Sta cosa è strana, ma non so bene come venga calcolato l'hash. Potrebbe avere a che fare con la cluster size, o qualcosa del genere? Magari l'hash è calcolato a blocchi, e i due dischi non hanno la stessa struttura dati di base. Puoi provare a formattare uno dei due, o una nuova partizione apposita, con dimensione cluster diversa, e fare qualche prova. - CRL - __________________ "non è compito del mod dare una mano di bianco sul grigio della vita" [cit.]

01-07-2008, 01:41	#6
CRL Senior Member Iscritto dal: Jun 2004 Città: London, UK Messaggi: 10708	Beh, cavolo, sta cosa non dovrebbe succedere. Vediamo se qualcuno più preparato interviene a dirci qualcosa, il controllo CRC c'è già sul cavo, se no chi sa cosa verrebbe copiato, ci sono un mare di errori e ritrasmissioni in tutte le operazioni di copia, non capisco perchè in questo caso non vengano rilevate. La ECC costa cifre spropositate, e comunque non credo risolverebbe, perchè in questo caso è il box che deve rispondere e restituire il CRC del pacchetto ricevuto, e se è diverso da quelo spedito il dato viene ritrasmesso. - CRL - __________________ "non è compito del mod dare una mano di bianco sul grigio della vita" [cit.]

01-07-2008, 02:08	#7
Link Wolf Senior Member Iscritto dal: Jun 2008 Città: Prypiat Messaggi: 564	Bhe ragazzi dopo che mi avete sollevato questo dubbio atroce mi son rimboccato le maniche ed ho fatto qualche prova: Da disco singolo NTFS 4K cluster a RAID0 NTFS 4K cluster, tutto ok: Da disco singolo NTFS 4K cluster a Ramdrive FAT32 ??K cluster, tutto ok Altri test al prossimo edit... EDIT: File copiato più volte da: NTFS 4K cluster a pendrive FAT a ramdrive NTFS 512 byte e poi verificato checksum MD5 tra file del primo disco e quello dell'ultimo: __________________ Ultima modifica di Link Wolf : 01-07-2008 alle 02:25.

01-07-2008, 02:59	#8
havanalocobandicoot Senior Member Iscritto dal: Jun 2005 Messaggi: 4057	Hai fatto la prova con file piccoli o anche molto grossi? Perché anche col controller schifoso cinese io ho copiato decine di GiB senza errori di hash... E poi il problema penso sia proprio là, e che se copiassi un file da 10 GB dal primo hard disk interno al secondo, e poi prendessi questo e lo ricopiassi sul primo, e così via altre 100 volte, probabilemente alla fine il file avrebbe hash corretto, proprio perché magari una scheda madre lavora meglio di uno schifo di cavetto cinese. Però quando il controller non lavora bene, Windows me lo deve dire... inutile che devo fare io un controllo hash su ogni file che copio... dai... __________________ >>>>> Benchmark di velocità in lettura di tutte le periferiche di memorizzazione <<<<< OCCHIO A VISTA E A WINDOWS 7! - HANNO DECISO DI NON FIDARSI DI TE! GUARDA IL VIDEO *Uno dei difetti dell'open source è la troppa libertà, e, ad oggi, il decentramento delle energie. El pueblo unido jamás será vencido!* Ultima modifica di havanalocobandicoot : 01-07-2008 alle 03:02.

14-07-2008, 01:44	#10
havanalocobandicoot Senior Member Iscritto dal: Jun 2005 Messaggi: 4057	up __________________ >>>>> Benchmark di velocità in lettura di tutte le periferiche di memorizzazione <<<<< OCCHIO A VISTA E A WINDOWS 7! - HANNO DECISO DI NON FIDARSI DI TE! GUARDA IL VIDEO *Uno dei difetti dell'open source è la troppa libertà, e, ad oggi, il decentramento delle energie. El pueblo unido jamás será vencido!*

14-07-2008, 10:47	#11
Pinucciotronic Bannato Iscritto dal: Dec 2007 Messaggi: 153	Ciao, solo per segnalare che anche io ho riscontrato problemi similari. Ho una catena RAID dove il copia/incolla non ha MAI prodotto errori, mentre una diversa catena RAID SATA, produce talora errori sopra il giga. Mi fido talmente poco dei processi generici di windows, che per i trasferimenti uso dei software specifici (trovo valido, "viceversa" con controlli interni. Concordo assolutamente con te; se si tratta di un problema software di windows, sarebbe davvero una pessima cosa.

14-07-2008, 22:49	#15
Pinucciotronic Bannato Iscritto dal: Dec 2007 Messaggi: 153	Vai a farti benedire.

14-07-2008, 22:57	#17
Pinucciotronic Bannato Iscritto dal: Dec 2007 Messaggi: 153	Grazie per il cartellino giallo...l'ho speso bene e e di cuore.

19-07-2008, 03:57	#18
havanalocobandicoot Senior Member Iscritto dal: Jun 2005 Messaggi: 4057	up __________________ >>>>> Benchmark di velocità in lettura di tutte le periferiche di memorizzazione <<<<< OCCHIO A VISTA E A WINDOWS 7! - HANNO DECISO DI NON FIDARSI DI TE! GUARDA IL VIDEO *Uno dei difetti dell'open source è la troppa libertà, e, ad oggi, il decentramento delle energie. El pueblo unido jamás será vencido!*

19-07-2008, 09:18	#19
sim89 Messaggi: n/a	Iscritto e interessato Ogni giorno copio/sposto tanti di quei gb che non avete neanche idea. Questo thread mi ha fatto cadere le braccia

19-07-2008, 09:53	#20
DVD_QTDVS Bannato Iscritto dal: Jun 2007 Città: MILANO Messaggi: 91	Per gli utenti più evoluti, i nodi iniziano ad arrivare al pettine, alla faccia di chi diceva, il nuovo è meglio, perchè ti fai tutte queste seghe mentali.. ecc. ecc. La verità è che le normali ddr e ddr2 sono delle memorie da videogame, e così pure alcuni sistemi operativi, il cui unico scopo principlae è difendere il DRM e permettere l'accesso ai dati da parte della software house, virus e spyware, così da far girare anche il mercato di altri prodotti softuare.. Ok, detto questo passiamo alla parte pratica... Prima di tutto è necessario controllare la Ram con memtest86, senza overclock, xchè l'overclock di bus può gengerare errori. Anche un solo errore può compromettere il file salvato. Se la ram è ok si passa ad uno scan dei settori dell' hard disk con HdTune, e sarebbe pure opportuno controllare i parametri smart. Questo controllo si può eseguire pure con le Seatools, preferibilmente a disco vuoto. Poi c'è da considerare il fatto che il sistema NTSF comprime alcuni file o parti di file, e questo è molto pericoloso x l'integrità dei dati, perchè quando il file viene copiato, viene anche elaborato, e quindi la possibilità di errore viene elevata di potenza N.. Per i file corrotti io proverei a fare un confronto bit a bit per vedere quali parti risultano diverse, se pochi bit oppure interi cluster. D'altra parte se i computer della classe workstation o mainframe, adottano memoria ECC, e sistema operativo Unix con md5 ci sarà pure un perchè..

Strumenti
Mostra una versione stampabile Invia questa pagina per email