Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
Ciao a tutti,
è da un secolo che non scrivo sul forum, e torno oggi con una domanda.. Devo copiare una gran quantità di files di dimensioni variabili (da pochi KB a centinaia di MB), la copia deve avvenire tra un disco sata e un volume virtuale creato con lvm, quindi filesystem e dischi diversi...
Dopo questa doverosa premessa, la domanda è: è più veloce cp o mv in questo caso?? E' chiaro che non mi interessa mantenere i files sul disco di origine, quindi userei cp solo nel caso in cui fosse più veloce...
Mario Vanoni ha scritto:Preferisco cp, se succede un errore con mv ...
che tipo di errore? mv prima effettua una copia (in caso di fs differenti, altrimenti fa un hard link) e se non ci son stati errori fa l'unlink; ovviamente non fa un checksum dei file (o addirittura un confronto bit a bit), ma l'unico modo per aver problemi è che il kernel o le libc mentano sul risultato delle write, il che, a meno di un grosso bug del kernel o delle libc (di cui ci si sarebbe gia accorti), è impossibile.
Mario Vanoni ha scritto:Preferisco cp, se succede un errore con mv ...
che tipo di errore? mv prima effettua una copia (in caso di fs differenti, altrimenti fa un hard link) e se non ci son stati errori fa l'unlink; ovviamente non fa un checksum dei file (o addirittura un confronto bit a bit), ma l'unico modo per aver problemi è che il kernel o le libc mentano sul risultato delle write, il che, a meno di un grosso bug del kernel o delle libc (di cui ci si sarebbe gia accorti), è impossibile.
Sei andato troppo nello specifico e non serviva, se per sbaglio si interrompe la copia, vuoi per il fs di destinazione pieno o per un black out, il file lasciato a metà viene perso, con cp inizi da capo e via.
Mario Vanoni ha scritto:Preferisco cp, se succede un errore con mv ...
che tipo di errore? mv prima effettua una copia (in caso di fs differenti, altrimenti fa un hard link) e se non ci son stati errori fa l'unlink; ovviamente non fa un checksum dei file (o addirittura un confronto bit a bit), ma l'unico modo per aver problemi è che il kernel o le libc mentano sul risultato delle write, il che, a meno di un grosso bug del kernel o delle libc (di cui ci si sarebbe gia accorti), è impossibile.
Sei andato troppo nello specifico e non serviva,
perchè non serviva?
se per sbaglio si interrompe la copia, vuoi per il fs di destinazione pieno o per un black out, il file lasciato a metà viene perso, con cp inizi da capo e via.
eh? con mv nei casi da te descritti non viene fatto l'unlink del file da copiare, quindi non perdi nulla (ma se tu avessi letto quel che ho scritto sopra, gia lo sapresti)
Io non ho detto che sia errato, parlo per esperienza, con mv al di là di tutto ho perso qualche file in passato, uso solo cp per grossi spostamenti di file, non vedo superbia nella mia risposta, il tuo intervento è fuori luogo, non servono avvocati per una normale conversazione.
Anche io so, come masalapianta, che il file non viene cancellato se non è arrivato sano e salvo a destinazione.
Tanto è vero che potete da voi stessi fare una prova. Iniziate a spostate un file (di grosse dimensioni) da un filesystem ad un altro (così perdete più tempo) e poi ammazzate 'mv' con 'killall -s 9 mv' (così non perdete tempo a trovare il PID esatto) e vedete cosa succede. Ricordo che il SIGKILL ('-s 9' di killall) non è intercettabile e quindi 'mv' viene ucciso impedendogli di terminare correttamente. Alla fine troverete il vostro file iniziale intatto e un altro parziale dall'altra parte.
Emanuele
Linux Registered User #454438 Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama 20/04/2013 - Io volevo Rodotà
It first uses some of the same code that's used by `cp -a'
to copy the requested directories and files, then (assuming the copy
succeeded) it removes the originals. If the copy fails, then the part
that was copied to the destination partition is removed. If you were
to copy three directories from one partition to another and the copy of
the first directory succeeded, but the second didn't, the first would
be left on the destination partition and the second and third would be
left on the original partition.
Fonte: coreutils.
Faccio i complimenti alla spaventosa conoscenza di masalapianta.
spina ha scritto:Anche io so, come masalapianta, che il file non viene cancellato se non è arrivato sano e salvo a destinazione.
Tanto è vero che potete da voi stessi fare una prova. Iniziate a spostate un file (di grosse dimensioni) da un filesystem ad un altro (così perdete più tempo) e poi ammazzate 'mv' con 'killall -s 9 mv' (così non perdete tempo a trovare il PID esatto) e vedete cosa succede. Ricordo che il SIGKILL ('-s 9' di killall) non è intercettabile e quindi 'mv' viene ucciso impedendogli di terminare correttamente. Alla fine troverete il vostro file iniziale intatto e un altro parziale dall'altra parte.
Emanuele
Ho fatto la prova con un flle video divx. copiato a parte per la prova.
Risultato: è proprio cosi..
Devo dire che ero peprlesso, perchè una volta ho perso davvero qualche file, ma ho usato taglia e incolla da GUI (Konqueror per l esattezza).
Masala non si batte
Offtopic: ragazzi, scusate l'offtopic ma tutti questi complimenti a masalapianta mi hanno fatto venire in mente un ricordo d'infanzia.
Emanuele
Linux Registered User #454438 Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama 20/04/2013 - Io volevo Rodotà