Newsgroup: it.comp.os.linux.iniziare
Titolo: USB-storage To CD: corruzione

Dovrei passare il contenuto di una chiavetta usb formattata
probabilissimamente in fat, su 3 cd.
La chiavetta contiene 2 GB di roba soprattutto mp3.
Sono solito utilizzare strumenti da linea di comando.
Leggendo qua e la ho visto che la strada potrebbe passare per:
- mkisofs: copia della directory intera in un'immagine iso
della stessa (devo passare la roba dalla chiavetta ad un HD
esterno sempre usb, in quanto non ho spazio sufficente nel
HD interno).
- qualcosa che spezza il file iso in tre parti di opportuna
  dimensione (che stiano nei cd insomma).
- cdrecord per masterizzare le tre immagini sui tre cd.
Ho deciso di chiedere qui, perch� avendo provato a fare un
tentativo di creazione dell'iso, direttamente dalla chiavvetta
all'immagine:
------------------------------------------
mkisofs -J -r -o usbkey-musica.iso musica/
mount usbkey-musica.iso /media/musica/ -o loop=/dev/loop1
mplayer /media/musica/brano-prova.mp3
[...]
Playing /media/musica/brano-prova.mp3.
Seek failed
[...]
---------->   <ctrl+c>   <-------------------------------|
le cose non mi tornano.
Infatti alcuni brani mp3 che sulla chiavetta funzionano, se
riprodotti dall'immagine iso creata e montata in loop non fungono
e mplayer dice seek failed.
Prima di bruciare i cd ho cos� pensato di chiedere a voi
eventuali procedure abastanza sicure per evitare casini e creare
tre immagini funzionanti tanto quanto i files nella chiavetta che
sono comunque funzionanti.

 sono comunque funzionanti.
Vedo che non ci sono state risposte...
Provo a girare la domanda:
avendo una penna storage usb formattata banalmente in fat,
come copiarne il contenuto in una partizione di un HD esterno
collegato sempre via usb al PC, ma formattato in ext3?
Intendo qual � un modo piuttosto sicuro al fine di preservare
l'utilizzabilit� dei dati. Sempre che ci sia un metodo pi�
affidabile di altri...
� strano, ma non saprei spiegare perch� mplayer riproduce senza
problemi un brano dalla chiavetta, mentre ritorna errore se si
tenta di riprodurre lo stesso brano ma dalla copia fatta sull'HD.

 La chiavetta contiene 2 GB di roba soprattutto mp3.
]zac[
Premesso che conviene masterizzare un dvd, forse puoi fare un archivio tar e
poi usare split per dividerlo in file da 650/750 Mb.
I file splittati si uniscono con cp filea fileb filec filetutto

 Perche' la copia non e' venuta bene ovviamente.
Ok, mi sembrava ovvio anche a me, ma non avendo molta esperienza
in materia... insomma, grazie per la conferma.
Sintetizzando:
0- ho provato cp -R /media/chiavetta/* /media/HD/dest.chiavetta/
1- ottengo i due errori sopra, circa i file che ho indicato come
   pippo.mp3 e pluto.mp3
2- mplayer riproduce in modo random pippo.mp3 sulla chiavetta
 - mplayer riproduce correttamente la copia di pippo.mp3 sull'HD
 - mplayer non riproduce in nessun modo pluto.mp3 sulla chiavetta
 - mplayer non riproduce in nessun modo pluto.mp3 copiato sull'HD
Che fare?
(lo so la domanda � molto generica, ma mi piacerebbe capire cosa
fareste voi in questo caso per cercare di risolvere).


Ho qualche dubbio sull'accesso.
Il dvd lo devo bocciare perch� il lettore che dovr� riprodurre i
files, ripeto stiamo parlando in gran parte di mp3, non legge
altri supporti oltre al CD... almeno penso.
C'� anche qualche video avi, che a questo punto potrei anche
evitare di copiare... vista la destinazione d'uso riproduzione
audio-only.
E anche l'archiviazione con tar mi sa che non va bene. Perch� poi
come fa il lettore (si tratta di un autoradio) ad accedere
all'archivio.
A questo punto probabilmente mi sono espresso male io mi sa:
infatti si vorrebbe avere 3 CD utilizzabili su un autoradio.
Quindi copiare il contenuto della chiavetta su tre CD, ma lo
split deve essere fatto in modo tale da non tranciare un file a
met�... altrimenti si avrebbe un brano che inizia su un cd e
finisce sull'altro... no buono!
Ad ogni modo vorrei prima riuscire a vederci pi� chiaro sui
problemi di copia che saltano fuori.

 avrebbe un brano che inizia su un cd e finisce sull'altro... no buono!
[...]
ci sarebbe (se funziona con wine)
*Sizeme*
- 
http://www.qweas.com/download/system/disk_tools/sizeme.htm
f/up su it.comp.os.linux.software
-- 
Puppy Linux wiki:  
http://puppylover.netsons.org/dokupuppy
Puppy Linux Forum: 
http://puppylinux.ilbello.com
Windows me genuit, Ubuntu rapuere / tenet nunc Puppy Linux...

 Considerare la chiavetta andata e buttarla via.
Gi�... � che non � mia. A me han detto:
- mi passeresti la chiavetta su dei cd?
- da quanto �?
- 2GB
- ok, dammi 3 CD
Prima veniva usato un autoradio con porta usb che leggeva
direttamente la chiavetta. Ora invece, stereo nuovo ma senza usb.
Sembrava una operazione banale, ma al solito murphy con cui
spesso gestisco a quattro mani le diavolerie informatiche che ho
a disposizione... ha voluto strafare.  :-\
In ogni caso mi sa tanto che hai ragione.
Ho provato un attimo ad ipotizzare diverse cause al problema.
- errore durante la copia dovuto a qualche non meglio precisaa
  gestione buffer visto che si tratta di devices esterni... non
  si sa mai.
- chiavetta andata o filesistem della stessa andato, o
  semplicemente files corrotti a tal punto da compromettere un
  processo di copia.
Per vedere un'alternativa, ho anche provato qualcosa a basso
livello sperando in dd. Mi sono detto se ho tutto su un unico
disco, magari ci sono meno possibilit� di casini. Cos� ho
smontato la chiavetta e provato con:
==========================================
# dd if=/dev/sdb1 of=/media/HD/chiavetta.img
dd: reading `/dev/sdb1': Input/output error
794592+0 records in
794592+0 records out
406831104 bytes (407 MB) copied, 46.7337 s, 8.7 MB/s
====================================================
Ecco che salta fuori un errore non molto locuace, ma va b�.
Riprovo:
===========================================
dd: reading `/dev/sdb1': Input/output error
970208+0 records in
970208+0 records out
496746496 bytes (497 MB) copied, 57.1542 s, 8.7 MB/s
====================================================
Sono spariti 90 MB di dati copiati, eppoi non ci siamo, perch� il
device � da 2 GB:
===================
# fdisk -l /dev/sdb
Disk /dev/sdb: 2063 MB, 
2063597568
 bytes
16 heads, 32 sectors/track, 7872 cylinders
Units = cylinders of 512 * 512 = 262144 bytes
Disk identifier: 0x00000000
   Device Boot      Start         End      Blocks   Id  System
	/dev/sdb1   *           1        7872     2015216    e  W95
	FAT16 (LBA)
==============================================================
Perch� mi deve copiare solo 497 MB?
Provo cos� a copiare tutto il device /dev/sdb, non la partizione.
Ahh, io non sono esperto nell'uso di dd, magari vi erano
opzioni particolari da passare in casi come questo, no so.
=====================================================
# dd if=/dev/sdb of=/media/HD/chiavetta-alldevice.img
dd: reading `/dev/sdb': Input/output error
970208+0 records in
970208+0 records out
496746496 bytes (497 MB) copied, 58.5704 s, 8.5 MB/s
====================================================
C'� qualcosa che non torna...
Provo per sport a vedere cosa dice fdisk applicato a quel
dispositivo fasullo frutto del tentativo di copia.
==================================
# fdisk -l chiavetta-alldevice.img 
You must set cylinders.
You can do this from the extra functions menu.
Disk chiavetta-alldevice.img: 0 MB, 0 bytes
16 heads, 32 sectors/track, 0 cylinders
Units = cylinders of 512 * 512 = 262144 bytes
Disk identifier: 0x00000000
Device                  Boot  Start   End   Blocks  Id           System
chiavetta-alldevice.img1   *      1  7872  2015216   e  W95 FAT16 (LBA)
Partition 1 has different physical/logical endings:
     phys=(703, 15, 32) logical=(7871, 15, 32)
==============================================
Eppure la copia con cp quindi a livello pi� alto, � riuscita
meglio, nel senso che comunque sono stati copiati 1.9 GB di roba
e non questi 497MB che ottengo con dd. BohOoo...
Ora, il punto �: cosa si potrebbe fare.
Prenderei in considerazione anche qualche soluzione "sporca"
per riuscire a copiare il tutto nel miglior modo possibile.
Vi lascio leggere il post che sta gi� diventando troppo lungo.
Nel frattempo come punto di partenza prendo in considerazione
consiglio circa la creazione di hash con md5sum, provo cos�:
find /media/chiavettausb -type f -exec md5sum "{}" \; > hash.orig
find /media/chiavettausb -type f -exec md5sum "{}" \; > hash.copied
In pratica genero du files di testo fatti cos�:
hash nomefile
se i files sono uguali (penso che diff vada bene a questo fine)
allora la copia � riuscita e probabilmente � il meglio che si
riesce a fare (se qualce files sar� corrotto, lo era anche prima
sulla chiavetta...queso � il senso dell'hash identico no?).
Saluti.

per riuscire a copiare il tutto nel miglior modo possibile.
Premesso che ci ho perso un po' la mano con queste cose, ma...
dd copia solo una parte perch� ad un certo punto trova un errore e si
ferma.
Cerca in rete ddrescue o dd_rescue (in questo momento non ricordo quale
� meglio) e riprova.
-- 
Antonio :-D

  dimensione (che stiano nei cd insomma).
Spezzare il file iso non credo sia una cosa buona.... devi creare 3 iso
separate.
Crei tre directory e verifichi le dimensioni. Per il calcolo della
dimensione del CD puoi appoggiarti sempre a mkisofs.
Ad esempio:
###
SETTORI=`mkisofs -R -quiet -print-size $2`
DIM_KB=$(($SETTORI*2))
DIM_MB=$(($DIM_KB/1024))
echo -e "Spazio necessario: $DIM_MB MB"    
###
Ciao.
-- 
Antonio :-D


Penso che in ogni caso, poi occorra verificare i singoli files
(brani) con md5sum.
Quindi tanto vale tentare prima con cp, che sembra che abbia
praticamente funzionato.
O magari nel caso in cui si ritenga opportuno copiare a basso
livello tutto quanto, si potrebbe anche provare a lanciare dd in
modo che ingori in qualche modo l'errore e prosegua nella copia.

 ###
Grazie.

 sulla chiavetta...queso � il senso dell'hash identico no?).
Allora, l'obiettivo principale � ottenere una copia delle varie
directories con i vari brani funzionanti, cio� riproducibili
nella copia almeno tanto quanto lo sono sulla chiavetta d'origine.
D'altro canto, penso che si possa affermare che se i singoli
files (brani mp3) originali e i corrispondenti files copiati
hanno lo stesso hash generato con md5sum, sono "digitalmente"
la stessa cosa e di conseguenza, se viene riprodotto l'originale
in modo corretto "deve" essere riproducibile identicamente la sua
copia.
Per questo l'idea proposta da Davide mi pare ragionevole e la
terrei come punto di partenza.
Come dicevo sopra, riesco a genereare i due files nel modo
indicato, quindi con find.
Ma, purtroppo i due files generati non sono confrontabili con
diff...mi spiego:
il file prodotto � del tipo:
HASH PERCORSO/NOME_FILE
Il problema � che l'ordine dei nomi dei brani non � lo stesso nei
due file di testo. Per cui il diff su di essi ha poco senso:
Ad esempio:
---- hash.orig-----
hash1 path1/brano1
hash2 path2/brano2
hash3 path3/brano3
...
-------------------
---- hash.copied --
hash2 path2/brano2
...
hash3 path3/brano3
...
hash1 path1/brano1
...
-------------------
Quindi magari gli hash sono anche uguali, ma i records sono
incopatibili nei due files di testo generati.
Se non mi sono spiegato bene chiedete pure, non esitate!  ;-)
Ora, il punto � generare e rimaneggiare i files di testo in modo
che siano coerenti, ovvero che vengano ordinati in imodo analogo.
In tal modo si pu� dare tutto in pasto a diff.
Provo un po'....
Se aveste idee in merito, precisazioni, correzioni da fare ecc,
dite pure.  grazie in anticipo :-)

> find /media/chiavettausb -type f -exec md5sum "{}" \; > hash.copied
� banale, ma l'errore c'�, la seconda riga � sbagliata, perch�
l'ho copiaincollata dalla prima senza poi modificarla:
find /media/HDext/copiakey -type f -exec md5sum "{}" \; > hash.copied
Dove ovviamente copiakey � la dir del'HD esterno in cui si �
copiata la chiavetta usb.

 
Magari non ho seguito bene tutta la discussione, ma a questo punto non ti 
conviene copiare il tutto con rsync che gia' di suo verifica con cheksum 
quello che copia?
Dal man rsync : 
-c, --checksum
[...]
Note  that  rsync  always verifies that each transferred file was correctly 
reconstructed on the receiving side by checking a whole-file checksum that 
is generated as the file  is  transferred, but  that automatic after-the-
transfer verification has nothing to do with this option’s before-             
the-transfer “Does this file need to be updated?” check.
Alessandro.

 before-the-transfer ?Does this file need to be updated?? check.
Come userste rsync per copiare da partizione fat16 in cui �
formattata la chiavetta alla dir di destinazione che � su una
partizione dell'HD esterno formattata in ext3?
Avevo provato con un semplice
rsync -avz surce/ dest/
Ora riprovo magari cercando info in merito alla differenza dei
due filesystem. E aggiungendo l'opzione --checksum.

 due filesystem. E aggiungendo l'opzione --checksum.
Va b�, ho copiato con:
rsync -avzc source/ dest/
e ha funzionato salvo per 3 files che falliscono per
input/output error, pare che rsync non riesca proprio a generare
l'hash per quei files.
Ho controllato la riproducibilit� dei 3 files. 2 sono
riproducibili e 1 no. Alla fine mi accontento lasciando perdere
quell'unico file che tanto non sar� stato riproducibile neanche
prima...
Gli altri due file di cui fallisce la copia con rsync per via del
fallimento cheksum, li ho copiati senza problemi con cp, provate
a riprodurre anche le copie e pare funzionare tutto bene. Cosi
alla fine li ho aggiunti alla dir di destinazione.
Adesso devo splittare la dir totale in tre parti... non so se ci
sono software ad hoc. Ma la butto l� per curiosit�, infatti
pensavo di fare a mano per non spaccare un album in due per
esempio...
Ok, saluti e grazie per il tempo che avete dedicato a rispondere.

 a rispondere.
Ho creato le 3 immagini con mkisofs.
Sto testando la masterizzazione simulandola con cdrecord -dummy,
ma ottengo uno strano warning.
Da google ci sto capendo poco circa quell'avvertimento ed a cosa
sia imputabile... volevo solo chiedere se � il caso di rischiare
la masterizzazione oppure no.
# cdrecord -dummy dev=/dev/cdrw speed=8 cd1.iso
cdrecord: No write mode specified.
cdrecord: Asuming -sao mode.
cdrecord: If your drive does not accept -sao, try -tao.
cdrecord: Future versions of cdrecord may have different drive
                                            dependent defaults.
Cdrecord-ProDVD-ProBD-Clone 2.01.01a57 (i686-pc-linux-gnu)
                         Copyright (C) 1995-2009 J�rg Schilling
scsidev: '/dev/cdrw'
devname: '/dev/cdrw'
scsibus: -2 target: -2 lun: -2
Warning: Open by 'devname' is unintentional and not supported.
Linux sg driver version: 3.5.27
Using libscg version 'schily-0.9'.
Device type    : Removable CD-ROM
Version        : 0
Response Format: 2
Capabilities   :
Vendor_info    : 'TOSHIBA '
Identifikation : 'ODD-DVD SD-R6372'
Revision       : '1732'
Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM.
Using generic SCSI-3/mmc   CD-R/CD-RW driver (mmc_cdr).
Driver flags   : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R96R
cdrecord: Warning: The DMA speed test has been skipped.
Starting to write CD/DVD/BD at speed 8 in dummy SAO mode for
                                              single session.
Last chance to quit, starting dummy write    0 seconds.
                                            Operation starts.
cdrecord: WARNING: Drive returns wrong startsec (0) using -150
Track 01: Total bytes read/written: 714954752/714954752
                                             (349099 sectors).
--------------------------------------------------------------
Che dite? Vado con la masterizzazione??

 due filesystem. E aggiungendo l'opzione --checksum.
Vedo che hai risolto, comunque, per usi futuri, dell'opzione checksum in 
questo caso non ne avevi bisogno, perlomeno questo e' quanto ho capito 
leggendo il man... :-)
--checksum verifica infatti tramite un hash se il file ha bisogno di essere 
aggiornato o meno, invece di usare mtime/ctime del file stesso come fa di 
solito. Se usi rsync solo per copiare (cioe' la destinazione e' vuota), il 
checksum non viene ovviamente usato. 
La parte del man che ho citato sottolinea che rsync effettua invece *sempre* 
il checksum della copia creata rispetto all'originale.
Alessandro

 Grazie.
Aggiungerei anche un altro metodo, usi k3b (grafico) con le librerie
aggiuntive per gli mp3, crei un progetto cd audio e aggiungi i file mp3
(possibilmente dal disco), k3b fa al volo la trasformazione da mp3 a raw,
in più puoi vedere lo spazio occupato sul cd, quando è pieno masterizzi e
passi all'altro.


aggiorno un attimo la situazione:
la masterizzazione non sembra aver funzionato in quanto il cd
creato non funziona.
Ho provato anche da altra macchina a stampare la .iso sul cd
e su altri cd vuoti. In tutti i casi il cd non era utilizzabile
dall'autoradio e anche su altri PC con windows, si vedeva il suo
contenuto si e no... con frequenza un po' random.
A questo punto, il mio masterizzatore non c'entra... forse ho
creato delle iso un po' troppo grandi. Lo dico perch� alla fine
ho masterizzato creando un cd dati alla windows-way con un
software apposito e nell'inserire le stesse directory incluse
nella iso, veniva segnalato il riempimento del supporto un po'
azzardato (raffigurato in quel software con zona gialla).
Che sia questo il problema?
Sarebbe bastato fare delle iso un po' pi� piccole?
I due warning che ritorna cdrecord hanno qualcosa a che fare con
questo?
Come fare per non sbagliare la prossima volta e creare delle iso
della dimensione corretta rispetto alla capienza del supporto?
Grazie in anticipo, spero possiate darmi una risposta.

 della dimensione corretta rispetto alla capienza del supporto?
Non vedendo ancora nessuna risposta bench� l'argomento dovrebbe
essere assai comune, ho pensato di cambiare titolo.
Sotto il vecchio titolo trovate tutti i dettagli della vicenda.
Nel frattempo far� una ricerca per conto mio ed eventualmente
posto la possibile soluzione.  :-)