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

[havanalocobandicoot]

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]

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]

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]

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]

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!! :muro:
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!! :muro:
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!! :muro:
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]

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]

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:

http://img56.imageshack.us/img56/7642/md5ich8rmaxtorseagatequ3.th.jpg (http://img56.imageshack.us/my.php?image=md5ich8rmaxtorseagatequ3.jpg)


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

http://img528.imageshack.us/img528/7555/md5fatntfsqy5.th.jpg (http://img528.imageshack.us/my.php?image=md5fatntfsqy5.jpg)

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:

http://img507.imageshack.us/img507/7401/immagineue8.th.jpg (http://img507.imageshack.us/my.php?image=immagineue8.jpg)

[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... :rolleyes:

[Link Wolf]

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

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 :mad:

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

Intanto sto provando con un file di 20 GB a fargli il checksum dopo averlo "sbattuto"(:D) su vari dischi ;)

Eccolo :)
http://img47.imageshack.us/img47/7760/immaginehp9.th.jpg (http://img47.imageshack.us/my.php?image=immaginehp9.jpg)

[havanalocobandicoot]

up

[Pinucciotronic]

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]

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?

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?

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]

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]

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.

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.

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

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]

Vai a farti benedire.

[CRL]

Vai a farti benedire.

Prego?

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

- CRL -

[Pinucciotronic]

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

[havanalocobandicoot]

up

[sim89]

:eek:

Iscritto e interessato ;) Ogni giorno copio/sposto tanti di quei gb che non avete neanche idea.
Questo thread mi ha fatto cadere le braccia :cry:

[DVD_QTDVS]

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

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

Ok, detto questo passiamo alla parte pratica... :D

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

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è.. :sofico:

[havanalocobandicoot]

alla faccia di chi diceva, il nuovo è meglio
In che senso?

La verità è che le normali ddr e ddr2 sono delle memorie da videogame
Recentemente l'ho pensato pure io. In quel caso la corruzione di un bit è una cosa irrisoria.

Prima di tutto è necessario controllare la Ram con memtest86,
senza overclock, xchè l'overclock di bus può gengerare errori.
Non ricordo se ho fatto un Goldmemory test o un memtest86+, comunque le ram le ho testate, ho fatto anche 2 pass, tutto ok.
Sono delle OCZ DDR2-800 CL4, per cui le ho settate manualmente a 4-4-4-15, come dichiara il produttore. Di default erano viste come CL5 mi pare.
Non penso che questo possa essere considerato overclock, e non penso che c'entri molto.

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.
Cambiando il controller che gestiva il disco quando ha dato gli errori, al primo colpo non ha avuto più errori. Quindi secondo me era proprio colpa del controller schifoso, e purtroppo ce ne sono in giro mooolti di controller schifosi. Per mia esperienza, i controller cinesi da 4 soldi fanno schifo (corrompono i file), e non solo quelli (vedi l'unico controller IDE su PCI che ho provato). Io cerco di tenermi alla larga quanto più possibile da controller che non siano quelli del chipset.
Non ricordo se ho fatto un test con HD Tune, probabilmente l'avrò considerato superfluo.

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
Ma io so che questa cosa la fa sui file di sistema, e non sui dati, a meno di non dirglielo specificatamente.

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.
Io IPOTIZZO che fossero pochi bit, ma come si fa un controllo del genere? Il confronto bit a bit lo si fa con gli hash, ma se l'hash è diverso, effettivamente dall'hash non si capisce se è differenze 1 solo bit o 1000.

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è.. :sofico:
Ecco, io vorrei approfondire questo discorso dell'ECC. Perché se con l'ECC si ha la sicurezza matematica che un file venga copiato perfettamente (hash corretto) o che quando c'è un'errore mi venga in qualche modo segnalato, io cambio la scheda madre e la ram, che ho appena preso nuove da qualche settimana, e monto un sistema ECC! Sempre su Windows però.
E pensare che la "vecchia" 939 che ho tolto da poco aveva il supporto all'ECC! :muro:

[lupin87]

teracopy è quello che fa per te...ti permette di confrontare gli hash però funziona solo se fai la copia di un file non se lo sposti...attualmente io ho la versione 1.22 ma hanno fatto la 2.0 beta 3...non so se va bene

http://www.codesector.com/teracopy.php

[havanalocobandicoot]

teracopy è quello che fa per te...ti permette di confrontare gli hash però funziona solo se fai la copia di un file non se lo sposti...attualmente io ho la versione 1.22 ma hanno fatto la 2.0 beta 3...non so se va bene

http://www.codesector.com/teracopy.php
Finora quando ho trasferito enormi quantità di dati ho usato CD Check e/o confrontato gli hash manualmente oppure con HashTab.
TeraCopy lo sto provando da qualche giorno, promette cose interessanti, come la velocizzazione della copia (sembrerebbe strano, dato che se il transfer rate è quello, non vedo come lo si possa aumentare) ma non ho ancora capito come funziona esattamente il discorso del buffer, e perché quando copia da un hard disk ad un altro lo setta a 256 kB mentre all'interno dello stesso hard disk a 1 MB.
Variando il buffer, la copia avviene effettivamente in maniera più veloce, ma non so fino a che punto è affidabile variare la dimensione del buffer (esempio: e se si dà un buffer superiore a quello che ha il disco??).

Il controllo CRC dovrebbe sì farlo, ma occorre farlo ogni volta manualmente.
Inoltre ho ancora delle perplessità circa la bontà del suo funzionamento. Vediamo perché.

Recentemente ho copiato un file RAR con TeraCopy. Sarà stato qualche centinaio di MB. Beh, la copia del file aveva i cluster occupati fino all'orlo, anche se il file veniva estratto bene.
Cluster occupati fino all'orlo nel senso che, se per esempio il file originale era:
143.411.268 byte con spazio su disco 143.413.248 byte

...la copia del file era:
143.413.248 byte con spazio su disco 143.413.248 byte.

In rosso il valore che non mi sarei aspettato dalla copia. Non mi sono segnato i valori reali ma il concetto è questo.

Comunque Winrar l'ha estratto bene e dava la stessa dimensione del file (da Winrar: Utilità -> Informazioni).

Inoltre, quando sta copiando un file e lo si interrompe, non cancella il file che stava copiando (come fa Windows) ma lo lascia incompleto: occuperà di meno. Ora, questa sembra una cosa buona, e di fatti per certi versi lo è, anche se errori come quello riportato sopra mi portano a non guardare molto di buon occhio questo programma e la sua copia bit per bit.

[lupin87]

Finora quando ho trasferito enormi quantità di dati ho usato CD Check e/o confrontato gli hash manualmente oppure con HashTab.
TeraCopy lo sto provando da qualche giorno, promette cose interessanti, come la velocizzazione della copia (sembrerebbe strano, dato che se il transfer rate è quello, non vedo come lo si possa aumentare) ma non ho ancora capito come funziona esattamente il discorso del buffer, e perché quando copia da un hard disk ad un altro lo setta a 256 kB mentre all'interno dello stesso hard disk a 1 MB.
Variando il buffer, la copia avviene effettivamente in maniera più veloce, ma non so fino a che punto è affidabile variare la dimensione del buffer (esempio: e se si dà un buffer superiore a quello che ha il disco??).

Il controllo CRC dovrebbe sì farlo, ma occorre farlo ogni volta manualmente.
Inoltre ho ancora delle perplessità circa la bontà del suo funzionamento. Vediamo perché.

Recentemente ho copiato un file RAR con TeraCopy. Sarà stato qualche centinaio di MB. Beh, la copia del file aveva i cluster occupati fino all'orlo, anche se il file veniva estratto bene.
Cluster occupati fino all'orlo nel senso che, se per esempio il file originale era:
143.411.268 byte con spazio su disco 143.413.248 byte

...la copia del file era:
143.413.248 byte con spazio su disco 143.413.248 byte.

In rosso il valore che non mi sarei aspettato dalla copia. Non mi sono segnato i valori reali ma il concetto è questo.

Comunque Winrar l'ha estratto bene e dava la stessa dimensione del file (da Winrar: Utilità -> Informazioni).

Inoltre, quando sta copiando un file e lo si interrompe, non cancella il file che stava copiando (come fa Windows) ma lo lascia incompleto: occuperà di meno. Ora, questa sembra una cosa buona, e di fatti per certi versi lo è, anche se errori come quello riportato sopra mi portano a non guardare molto di buon occhio questo programma e la sua copia bit per bit.

per quanto riguarda il discorso del buffer questo va settato in base alla quantità dei dati che riesci a trasferire dalla periferica iniziale...cioè,ieri stavo copiando un divx da cd ad hdd e il buffer stava settato a 1 megabyte,però vidi che la velocità di trasferimento era pari a 4 megabyte al secondo e quindi settai il buffer a 4 megabyte..il buffer,è una memoria tampone e settandoil buffer a 4 megabyte/secondo vuol dire che ogni secondo il buffer si svuoterà e si riempirà di nuovo di 4 megabyte...se invece assegnavo al buffer una dimensione più piccola accadeva che non riuscivo a sfruttare pienamente l' ampiezza di trasferimento del supporto ottico in quanto ogni secondo si doveva svuotare e doveva "interrompere" il trasferimento dal masterizzatore,se invece imposto un valore alto il buffer ci mette molto a riempirsi però ci sono meno interruzioni del caso precedente...non so se settare il buffer maggiore o uguale allo spazio di trasferimento sia la stessa cosa,una cosa è certa:buffer troppo piccoli non conviene.quanto alla differenza tra dimensioni e dimensioni su disco,questo è un discorso che devo ancora approfondire meglio,ma se gli hash tra i 2 file sono uguali non credo ci siano problemi

qaunto all' affidabilità cosa mi consiglieresti in alternativa a teracopy pro?

[havanalocobandicoot]

per quanto riguarda il discorso del buffer questo va settato in base alla quantità dei dati che riesci a trasferire dalla periferica iniziale...cioè,ieri stavo copiando un divx da cd ad hdd e il buffer stava settato a 1 megabyte,però vidi che la velocità di trasferimento era pari a 4 megabyte al secondo e quindi settai il buffer a 4 megabyte..il buffer,è una memoria tampone e settandoil buffer a 4 megabyte/secondo vuol dire che ogni secondo il buffer si svuoterà e si riempirà di nuovo di 4 megabyte...se invece assegnavo al buffer una dimensione più piccola accadeva che non riuscivo a sfruttare pienamente l' ampiezza di trasferimento del supporto ottico in quanto ogni secondo si doveva svuotare e doveva "interrompere" il trasferimento dal masterizzatore,se invece imposto un valore alto il buffer ci mette molto a riempirsi però ci sono meno interruzioni del caso precedente...non so se settare il buffer maggiore o uguale allo spazio di trasferimento sia la stessa cosa,una cosa è certa:buffer troppo piccoli non conviene.
Il fatto che la velocità di trasferimento in quel momento fosse di 4 MB/s non significa che occorre settare il buffer a 4 MB. Non vedo il nesso.
Se imposto il buffer ad una dimensione superiore rispetto al buffer fisico del disco non è male?

quanto alla differenza tra dimensioni e dimensioni su disco,questo è un discorso che devo ancora approfondire meglio,ma se gli hash tra i 2 file sono uguali non credo ci siano problemi
L'hash era diverso.
SECONDO ME TeraCopy ha "tagliato male" il file, cioè ha scritto il file bene (o almeno lo spero), e poi ha riempito con non-so-cosa la parte vuota rimanente dei cluster occupati.

qaunto all' affidabilità cosa mi consiglieresti in alternativa a teracopy pro?
Non saprei, ho provato solo quello. :D
Ah, tu hai provato la versione pro? Ha dei vantaggi rispetto alla versione normale?

[lupin87]

Il fatto che la velocità di trasferimento in quel momento fosse di 4 MB/s non significa che occorre settare il buffer a 4 MB. Non vedo il nesso.
Se imposto il buffer ad una dimensione superiore rispetto al buffer fisico del disco non è male?


L'hash era diverso.
SECONDO ME TeraCopy ha "tagliato male" il file, cioè ha scritto il file bene, e poi ha riempito con non-so-cosa la parte vuota dei cluster occupati.


Non saprei, ho provato solo quello. :D
Ah, tu hai provato la versione pro? Ha dei vantaggi rispetto alla versione normale?

perchè è male?

hai provato per caso la versione beta?
sicuro che anche il tuo hdd sia integro?una scansione con hdtune non fa mai male...la copia è avvenuta sullo stesso disco o su dischi diversi?

si..sul sito penso ci sia la tabella con le features...

[havanalocobandicoot]

perchè è male?

hai provato per caso la versione beta?
sicuro che anche il tuo hdd sia integro?una scansione con hdtune non fa mai male...la copia è avvenuta sullo stesso disco o su dischi diversi?
Potrebbe essere male perché il buffer è per esempio 16 MB, e io gli dico di usare un buffer di 20 MB: come fa se l'hard disk ha meno buffer?

Se posso, evito sempre le versioni beta. Ho usato la 1.22.

Non penso proprio che l'hard disk abbia problemi. Non me ne ha mai dati, e HD Tune dice che è tutto ok. E poi ho ripetuto l'operazione e l'ha fatta bene se non ricordo male.
Ho fatto la copia da un hard disk ad un altro.

[lupin87]

Potrebbe essere male perché il buffer è per esempio 16 MB, e io gli dico di usare un buffer di 20 MB: come fa se l'hard disk ha meno buffer?

Se posso, evito sempre le versioni beta. Ho usato la 1.22.

Non penso proprio che l'hard disk abbia problemi. Non me ne ha mai dati, e HD Tune dice che è tutto ok. E poi ho ripetuto l'operazione e l'ha fatta bene se non ricordo male.
Ho fatto la copia da un hard disk ad un altro.

mi sa che non conviene perchè per caricare un buffer di 20 mega ha bisogno di 2 secondi:1 secondo per i primi 16 e un altro secondo per i restanti 4..hai ragione

stessa dimensione dei cluster tra un hdd e l' altro?

[havanalocobandicoot]

mi sa che non conviene perchè per caricare un buffer di 20 mega ha bisogno di 2 secondi:1 secondo per i primi 16 e un altro secondo per i restanti 4..hai ragione
A parte il fatto se convenga o meno... il mio dubbio è se può dare problemi o meno.
Ragionare in termini di secondi è comunque sbagliato: un trasferimento di 4 MB a 4 MB/s avviene in un secondo, ma un trasferimento di 4 MB a 3.90 MB/s avviene in 1.03 secondi.

stessa dimensione dei cluster tra un hdd e l' altro?
Sì, entrambe le partizioni degli hard disk a 4K.

[lupin87]

A parte il fatto se convenga o meno... il mio dubbio è se può dare problemi o meno.
Ragionare in termini di secondi è comunque sbagliato: un trasferimento di 4 MB a 4 MB/s avviene in un secondo, ma un trasferimento di 4 MB a 3.90 MB/s avviene in 1.03 secondi.


Sì, entrambe le partizioni degli hard disk a 4K.

non credo possa dare problemi comunque,secondo me,la soluzione migliore da adottare è quelal di settare la velocità del buffer uguale alla velocità di trasmissione dati della perferica di lettura...ogni 4 megabyte letti,4megabyte copiati senza evitare intasamenti di vario genere.

da dove l'hai vista la dimensione dei cluster?

[havanalocobandicoot]

da dove l'hai vista la dimensione dei cluster?
La puoi vedere con Partition Magic, oppure, empiricamente, dalla dimensione che un file da 1 byte (un documento di testo con all'interno 1 solo carattere) occupa su disco: quella è la dimensione del cluster, dato che il file, anche se pesa 1 byte, utilizza tutto il cluster, e cioè 4 kB. Questo perché in un cluster è possibile allocare un solo file.
Un file da 9 kB occuperà per esempio 3 cluster: i primi due saranno pieni, mentre il terzo avrà 3 kB sprecati. Su disco occuperà quindi 12 kB.

[lupin87]

La puoi vedere con Partition Magic, oppure, empiricamente, dalla dimensione che un file da 1 byte (un documento di testo con all'interno 1 solo carattere) occupa su disco: quella è la dimensione del cluster, dato che il file, anche se pesa 1 byte, utilizza tutto il cluster, e cioè 4 kB. Questo perché in un cluster è possibile allocare un solo file.
Un file da 9 kB occuperà per esempio 3 cluster: i primi due saranno pieni, mentre il terzo avrà 3 kB sprecati.

quindi,quando vado nelle proprietà,dimensioni sta a rappresentare le dimensioni del file mentre dimensioni su disco sta a rappresentare le dimensioni in base ai cluster...la partizione d quando la formattai come dimensione misi 512 byte...adesso posso trasformare la partizione C in cluster da 512 anzichè 4k?

[havanalocobandicoot]

quindi,quando vado nelle proprietà,dimensioni sta a rappresentare le dimensioni del file mentre dimensioni su disco sta a rappresentare le dimensioni in base ai cluster...la partizione d quando la formattai come dimensione misi 512 byte...adesso posso trasformare la partizione C in cluster da 512 anzichè 4k?
Siamo andati fuori tema. E' meglio aprire un'altra discussione se vuoi approfondire ulteriormente.
Comunque in teoria è possibile cambiare la dimensione dei cluster con Partition Magic ad esempio. Però se non ce n'è stretta necessità io non lo farei. Operare con la tabella di allocazione file è sempre un'operazione da fare con accortezza.
Tieni presente inoltre che avere una frammentazione eccessiva non è nemmeno buono, per le prestazioni del sistema. Di solito io uso il 4K, considerato un buon compromesso.

[lupin87]

Siamo andati fuori tema. E' meglio aprire un'altra discussione se vuoi approfondire ulteriormente.
Comunque in teoria è possibile cambiare la dimensione dei cluster con Partition Magic ad esempio. Però se non ce n'è stretta necessità io non lo farei. Operare con la tabella di allocazione file è sempre un'operazione da fare con accortezza.
Tieni presente inoltre che avere una frammentazione eccessiva non è nemmeno buono, per le prestazioni del sistema. Di solito io uso il 4K, considerato un buon compromesso.

ok era solo questa risposta che mi interessava,non vale la pena aprire un altra discussione...se trovi un programma più affidabile di teracopy avvisami

[emergo]

ok era solo questa risposta che mi interessava,non vale la pena aprire un altra discussione...se trovi un programma più affidabile di teracopy avvisami

Alternative a TeraCopy ce ne sono eccome:
CopyHandler (http://www.copyhandler.com/)
FastCopy (http://www.ipmsg.org/tools/fastcopy.html.en)
FFCopy (http://www.ffprojects.net/ffcopy/ffcopy.htm)
SuperCopier (http://supercopier.sfxteam.org/)
e non da ultimo (anzi forse il mio preferito) KillCopy (http://killprog.narod.ru/killcopye.html)

Da tenere inoltre in considerazione Unstoppable Copier (http://www.roadkil.net/program.php?ProgramID=29), specifico per la copia di files provenienti da supporti danneggiati (come CD o DVD).

Infine ci sono soluzioni più complete, i cosiddetti File Manager che consentono anche molte altre funzioni a parte quella della copia o spastamento, come rinominare, dividere, unire, cancellare, gestire files e cartelle etc... Fra questi nel campo freeware troviamo FreeCommander (http://www.freecommander.com/), che è abbastanza semplice, ma soprattutto xplorer2 lite (http://www.zabkat.com/x2lite.htm), che è la versione ridotta (e gratuita per uso personale) di un programma shareware di altissima qualità e con maggiori funzionalità (chiamato xplorer² (http://zabkat.com/)); nel campo shareware ci sono inoltre WinNC (http://www.winnc.com/) e Total Commander (http://www.ghisler.com/).

A voi la scelta

[lupin87]

Alternative a TeraCopy ce ne sono eccome:
CopyHandler (http://www.copyhandler.com/)
FastCopy (http://www.ipmsg.org/tools/fastcopy.html.en)
FFCopy (http://www.ffprojects.net/ffcopy/ffcopy.htm)
SuperCopier (http://supercopier.sfxteam.org/)
e non da ultimo (anzi forse il mio preferito) KillCopy (http://killprog.narod.ru/killcopye.html)

Da tenere inoltre in considerazione Unstoppable Copier (http://www.roadkil.net/program.php?ProgramID=29), specifico per la copia di files provenienti da supporti danneggiati (come CD o DVD).

Infine ci sono soluzioni più complete, i cosiddetti File Manager che consentono anche molte altre funzioni a parte quella della copia o spastamento, come rinominare, dividere, unire, cancellare, gestire files e cartelle etc... Fra questi nel campo freeware troviamo FreeCommander (http://www.freecommander.com/), che è abbastanza semplice, ma soprattutto xplorer2 lite (http://www.zabkat.com/x2lite.htm), che è la versione ridotta (e gratuita per uso personale) di un programma shareware di altissima qualità e con maggiori funzionalità (chiamato xplorer² (http://zabkat.com/)); nel campo shareware ci sono inoltre WinNC (http://www.winnc.com/) e Total Commander (http://www.ghisler.com/).

A voi la scelta

qual' è il migliore?ti permettono tutti di fare il controllo crc32 tra il file sorgente e quello destinatario per assicurarmi che la copia sia riuscita perfettamente?

[emergo]

qual' è il migliore?ti permettono tutti di fare il controllo crc32 tra il file sorgente e quello destinatario per assicurarmi che la copia sia riuscita perfettamente?

CIAO, per il controllo tra il file sorgente e quello destinatario ti consiglio FastCopy (http://www.ipmsg.org/tools/fastcopy.html.en), che tra le sue opzioni ne ha una chiamata 'Verify': "Verifying written files by MD5(or SHA-1. If you want to use SHA-1, write [main] Using_MD5=0 in fastcopy.ini)";
oppure puoi provare quello che preferisco io, KillCopy (http://killprog.narod.ru/killcopye.html), che tra le sue opzioni ne ha una chiamata 'Enable verifycation': "This opions enables additional copy verification, this slows down copy process up to 2 times but this can help when files transferred with errors without it, caused for example by bad connection to remote computer. Recommended to use high-speed mode with this option."

[lupin87]

CIAO, per il controllo tra il file sorgente e quello destinatario ti consiglio FastCopy (http://www.ipmsg.org/tools/fastcopy.html.en), che tra le sue opzioni ne ha una chiamata 'Verify': "Verifying written files by MD5(or SHA-1. If you want to use SHA-1, write [main] Using_MD5=0 in fastcopy.ini)";
oppure puoi provare quello che preferisco io, KillCopy (http://killprog.narod.ru/killcopye.html), che tra le sue opzioni ne ha una chiamata 'Enable verifycation': "This opions enables additional copy verification, this slows down copy process up to 2 times but this can help when files transferred with errors without it, caused for example by bad connection to remote computer. Recommended to use high-speed mode with this option."

ok grazie

[emergo]

ok grazie

Pensa che tempo fà feci la prova a copiare con TeraCopy dal mio HD interno una cartella di alcune decine di GB verso un HD esterno USB e ci impiegò 2 ore; KillCopy invece mi ha copiato la stessa cartella in 40 minuti!

[CRL]

emergo grazie mille, informazioni molto utili.

- CRL -

[shuttle]

Devi provare a spostare un file di grosse dimensioni da una partizione all’altra dello STESSO disco RIGIDO. La potenza di questi software sta nello sfruttare la memoria ram del pc in maniera tale da… prima leggere grossi blocchi (ad. es. buffer=50MB o più) e poi scriverli nell’altra partizione. Il furbo Windows invece, legge piccolissimi blocchi (meno di 1MB) e li scrive (sull’altra partizione) con il risultato di fare questa operazione migliaia di volte incidendo su prestazione, temperatura, consumi, e durata del disco.

[havanalocobandicoot]

Anche se un po' in ritardo, mi unisco ai ringraziamenti per Emergo.

Devi provare a spostare un file di grosse dimensioni da una partizione all’altra dello STESSO disco RIGIDO. La potenza di questi software sta nello sfruttare la memoria ram del pc in maniera tale da… prima leggere grossi blocchi (ad. es. buffer=50MB o più) e poi scriverli nell’altra partizione. Il furbo Windows invece, legge piccolissimi blocchi (meno di 1MB) e li scrive (sull’altra partizione) con il risultato di fare questa operazione migliaia di volte incidendo su prestazione, temperatura, consumi, e durata del disco.
Che vantaggio avrebbe utilizzare come sorgente il disco rigido di destinazione?
Forse non hai capito bene lo spirito col quale è nata la discussione. E' nata in seguito ad errori causati molto probabilmente dal controller di un box esterno. Ho espresso delle perplessità sull'attendibilità di Windows poiché non si accorge di questo tipo di errori; il discorso della velocità e del buffer non c'entra niente.

[shuttle]

Stavo effettuando una ricerca su TeraCopy ed ho letto solo quello che mi interessava al riguardo. In effetti non ho neanche letto l'argomento principale della discussione. Io ho solo risposto ad un tuo dubbio...

...
TeraCopy lo sto provando da qualche giorno, promette cose interessanti, come la velocizzazione della copia (sembrerebbe strano, dato che se il transfer rate è quello, non vedo come lo si possa aumentare) ma non ho ancora capito come funziona esattamente il discorso del buffer, e perché quando copia da un hard disk ad un altro lo setta a 256 kB mentre all'interno dello stesso hard disk a 1 MB.
Variando il buffer, la copia avviene effettivamente in maniera più veloce, ma non so fino a che punto è affidabile variare la dimensione del buffer (esempio: e se si dà un buffer superiore a quello che ha il disco??).
....

....
....

Che vantaggio avrebbe utilizzare come sorgente il disco rigido di destinazione?

e allora ripeto... TeraCopy et simili sono stati pensati in quei casi dove...
1) hai a disposizione un unico disco rigido diviso in 2 o più partizioni
2) devi spostare grossi file da una partizione ad un'altra
In queste condizioni, e solo in queste condizioni, stravelocizza lo spostamento con i vantaggi che ho già elencato.

ps
Ho dato adesso un'occhiata alla discussione. Interessante. Mi sa che seguo il consiglio di "Emergo". Tank's

[havanalocobandicoot]

... TeraCopy et simili sono stati pensati in quei casi dove...
1) hai a disposizione un unico disco rigido diviso in 2 o più partizioni
2) devi spostare grossi file da una partizione ad un'altra
In queste condizioni, e solo in queste condizioni, stravelocizza lo spostamento con i vantaggi che ho già elencato.
Mi continua a sfuggire perché il vantaggio si ha solo quando origine e destinazione stanno sullo stesso disco fisso, mentre quando stanno su dischi fissi diversi non si hanno miglioramenti della velocità.
Inoltre, le due condizioni sono entrambe necessarie (cioè se manca una delle due, non si hanno vantaggi in termini di velocità) o ciascuna è sufficiente (cioè ne basta una per avere il miglioramento)?

Mi sa che seguo il consiglio di "Emergo".
Quale dei tanti? :p

[shuttle]

Mi continua a sfuggire perché il vantaggio si ha solo quando origine e destinazione stanno sullo stesso disco fisso, mentre quando stanno su dischi fissi diversi non si hanno miglioramenti della velocità.

ok.

UN DISCO
Quando sposti un file da una partizione all'altra dello stesso disco, ciò che avviene è che la testina del disco deve, prima leggere un pezzo del file sorgente e subito dopo spostarsi fisicamente in una altra area del disco e scrivere il pezzo appena letto, poi ancora, deve riposizionarsi sul file sorgente, e così via fino alla fine. Più piccoli sono i pezzi letti più cicli di questo genere sono necessari per completare l'operzione. Questo provoca, tra l'altro, una gran perdita di tempo. Utilizzando windows credo si tratti di qualche mega corrispondente alla cache del disco(nel mio caso 1,5MB).
Killcopy, ovvia a questo inconveniente utilizzando un buffer(la velocissima memoria ram di sistema). Se ad es. imposti 128MB, significa che la testina legge i primi 128MB del file sorgente tutti in un fiato (memorizzandoli sulla RAM) per poi in seguito scriverli sull'altra partizione, sempre tutti in una volta.

DUE DISCHI
Quando sposti un file(di qualsiasi dimenzione) utilizzando due dischi, quello che avviene è che, il disco sul quale si trova il file sorgente, legge soltanto, spostando quindi la testina solo per eseguire la lettura di quel file. Il disco destinazione contemporaneamente scrive soltanto i blocchi che sono appena stati letti dal disco sorgente. Questa operazione avviene (quasi) alla massima velocita consentita dal disco, e anche se i blocchi letti sono di piccola dimenzione questo non influisce più di tanto, proprio perché la testina non è costretta a spostarsi continuamente.


Inoltre, le due condizioni sono entrambe necessarie (cioè se manca una delle due, non si hanno vantaggi in termini di velocità) o ciascuna è sufficiente (cioè ne basta una per avere il miglioramento)?

Be, il vantaggio c'e sempre, ma se sposti file piccoli neanche te ne accorgi. L'unica condizione necessaria è la copia da una partizione ad un'altra dello stesso disco.


Quale dei tanti? :p
L'utilizzo di killcopy. Inizialmente cercavo opinioni su teracopy. Comunque non ho ancora avuto modo di provarlo.

[havanalocobandicoot]

Grazie mille, sei stato davvero molto chiaro. :)
Mi rimarrebbe da "chiedere a TeraCopy": perché setti il buffer a 1 MB solamente quando origine e destinazione stanno sullo stesso disco fisso e non anche quando stanno su dischi diversi invece di settarlo a 256 kB? :D
Forse perché utilizzando un basso buffer la copia risulti potenzialmente più affidabile? http://img89.imageshack.us/img89/2020/thinkck8.gif
L'ultimo mio quesito è: questi programmi per velocizzare la copia, utilizzano prima il buffer, prima la memoria ram, metà e metà, oppure come capita?

[shuttle]

Grazie mille, sei stato davvero molto chiaro. :)
Mi rimarrebbe da "chiedere a TeraCopy": perché setti il buffer a 1 MB solamente quando origine e destinazione stanno sullo stesso disco fisso e non anche quando stanno su dischi diversi invece di settarlo a 256 kB? :D
Forse perché utilizzando un basso buffer la copia risulti potenzialmente più affidabile? http://img89.imageshack.us/img89/2020/thinkck8.gif

Questo non lo so. Non ho avuto il tempo di provare ne teracopy ne killcopy. 1MB comunque è poco se riferito alla ram di sistema. Se invece si tratta del "buffer" del disco probabilmente è normale. Fino ad ora ho utilizzato "Fastcopy" versione portatile su cui ho settato un "buffer" di 64MB. Ci sono comunque parecchie opzioni, molte delle quali le ho lasciate di default perché non ne conosco il funzionamento. In realtà, in questi giorni, sto rivalutando fastcopy, credo approfondirò il suo utilizzo prima di provare killcopy.


L'ultimo mio quesito è: questi programmi per velocizzare la copia, utilizzano prima il buffer, prima la memoria ram, metà e metà, oppure come capita?
Non lo so, ma il parametro più importante è sicuramente l'utilizzo della "memoria ram".

Ciao.

[havanalocobandicoot]

[...] il parametro più importante è sicuramente l'utilizzo della "memoria ram".
Questo perché la ram è sempre più veloce della cache del disco fisso, oppure perché utilizzando la ram aumenta comunque il buffer disponibile durante il processo di copia?
Essendo, sia la ram che la cache, fatti di chip di memoria (e per giunta entrambi di tipo volatile), qualunque delle due potrebbe essere la più veloce, giusto?

[shuttle]

Questo perché la ram è sempre più veloce della cache del disco fisso, oppure perché utilizzando la ram aumenta comunque il buffer disponibile durante il processo di copia?

La seconda.

Essendo, sia la ram che la cache, fatti di chip di memoria (e per giunta entrambi di tipo volatile), qualunque delle due potrebbe essere la più veloce, giusto?
Esatto. La differenza in gioco tra memorie RAM e velocità di un HD è di 1 a 50 come minimo.

[havanalocobandicoot]

Esatto. La differenza in gioco tra memorie RAM e velocità di un HD è di 1 a 50 come minimo.
Hai frainteso la mia frase. Io intendevo un confronto "ram vs cache", e non "ram vs hdd" o "cache vs hdd".
Infatti:
[...] qualunque delle due potrebbe essere la più veloce, giusto?
"La più veloce tra le due", e non "più veloce del disco fisso".

[shuttle]

Capisco la curiosità di quale delle due è più veloce (io non lo so), ma per quello che devono fare è ininfluente saperlo. Sappi solo che la differenza di prestazione tra disco e memorie RAM è abissale (a favore delle memorie ovviamente).

[havanalocobandicoot]

L'altro giorno ho scoperto un errore CRC su un altro box; ho descritto ampiamente l'esperienza nella discussione "Meraviglioso viaggio all'interno degli errori CRC su file video". Consiglio a tutti di darci un'occhiata. Ecco il link:
http://www.hwupgrade.it/forum/showthread.php?t=1926065