mv agire come cp(1) se l'autorizzazione allo spostamento del processo è negata?
Se sì, non è contro la regola fare una cosa e farla bene?
Risposta accettata:
La risposta breve è che non è così.
mv è definito in:
eseguire azioni equivalenti a rename() funzione
rename() non copia il contenuto, lo rinomina semplicemente su disco. È un'operazione completamente atomica che non fallisce mai parzialmente completata.
Questo non racconta l'intera storia, tuttavia. Dove questo effetto può succede quando si tenta di spostare un file tra dispositivi:in tal caso, non è possibile eseguire la ridenominazione nel filesystem. Per avere l'effetto di spostamento, mv prima copia la fonte nella destinazione, quindi elimina la fonte. In effetti, mv /mnt/a/X /mnt/b/Y è essenzialmente equivalente a cp /mnt/a/X /mnt/b/Y && rm /mnt/a/X . Questo è l'unico modo in cui lo spostamento di file tra dispositivi potrebbe funzionare.
Quando mv non ha il permesso di eliminare quel file sorgente, verrà segnalato un errore, ma a quel punto la copia è già avvenuta. Non è possibile evitarlo controllando in anticipo i permessi a causa di possibili condizioni di gara in cui i permessi cambiano durante l'operazione.
Non c'è davvero alcun modo per prevenire questa possibile eventualità, a parte rendere impossibile lo spostamento di file tra dispositivi. La scelta di consentire mv tra qualsiasi fonte e destinazione rende le cose più semplici nel caso generale, a scapito di comportamenti strani (ma non distruttivi) in questi casi insoliti.
Questo è anche il motivo per cui spostare un file di grandi dimensioni all'interno di un singolo dispositivo è molto più veloce che spostarlo su un altro.