Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

system disks



Today, David Kramer gleaned this insight:

> On Fri, 26 May 2000, Patrick McManus wrote:
> 
> > it is a heck of a lot safer than "cp -p *; rm *" though as you get per
> > file error checking..
> 
> I'm sorry.  As long as we're getting picky here, in my mind it is a LOT
> safer to cp then rm than it is to mv, because you can check the cp before
> you do the rm.  The mv is atomic, and if it didn't do what you want,
> you're SOL.

Using cp is certainly not safer if you do a "cp -p *; rm *" -- the effect
of both commands is identical.  It is only _conceivably_ safer if you do
the cp, then go and check that it did what you wanted (i.e. by checking
the checksums of the files if you actually want to be sure the data copied
properly...), and then go and do the rm. I could argue that practically
speaking, since you've still got a copy of the data _somewhere_, the
difference between the two methods is negligible.  The only case where it
makes a difference is if the target directory or directories exist and are
non-empty, and then you may end up copying the source into the target
(potentially mixing the data with other unwanted files), instead of over
the target, and thus making the recovery of that data in a form consistent
with its original form more difficult. However, this case is easily
avoided by paying attention to what you're doing.  One might argue that an
operator who does this deserves what they get, should chalk it up to a
lesson hard-learned, and thus this case should be ignored.

I could continue to argue that in either case, you are vulnerable to
hardware failure during the copy (if the source disk dies during the
copy), and in both cases you'll have to restore from backup after
replacing your failed disk, barring RAID, and assuming such a backup
exists. In the case of the target disk dying, you may experience data
loss.  But it isn't unlikely that the data is on the same physical disk,
in different partitions (especially since this is a Linux box that we're
talking about), so either way the disk will need to be replaced and the
data will need to be restored from backup (same assumptions about
existence of such). The number of cases where a cp is, practically
speaking, more beneficial than mv are insignificant.

However, an observer might point out that this is a really silly argument,
and we all should just shut up now.  :)

-- 
PGP/GPG Public key at http://cerberus.ne.mediaone.net/~derek/pubkey.txt
------------------------------------------------------
Derek D. Martin      |  Unix/Linux Geek
derekm at mediaone.net  |  derek at cerberus.ne.mediaone.net
------------------------------------------------------

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org