Move files by atomic rename instead of copy.
# $Header: /CVSROOT/mvatom/DESCRIPTION,v 1.4 2008-05-04 04:28:22 tino Exp $
#
# $Log: DESCRIPTION,v $
# Revision 1.4  2008-05-04 04:28:22  tino
# Option -s added
#
# Revision 1.3  2006-11-07 12:41:20  tino
# cmpanddel.sh added
#
# Revision 1.2  2006/08/12 02:07:38  tino
# corrected for option -o
#
# Revision 1.1  2006/07/22 23:47:58  tino
# First version for testing

Post-modern mv implementations re-invented a wheel which is no more
round.  If they cannot move they do a copy/unlink() operation which is
unsatisfying, as when the unlink() fails you stay with the copy which
was insanely done.

mv shall be an atomic operation.  However you cannot switch mv into
atomic mode.  This version here does what mv is supposed to do:

It renames the target and fails if it cannot do the rename.  It does
this using the rename() operation which is atomically (except for NFS,
but this is an NFS bug).

Another thing is that it only guesses something for the last argument
like mv does if it is instructed to do so.  So it always works
reliably.  You know what it does from looking at the command line, and
if no heuristics are given this does not depend from the last arg
beeing a directory or not.

If the destination is a directory this must be given as an option to
mvatom.  Also all options are simple and clear and there is no way to
overwrite files, as mvatom never overwrites files.

Also you can "move away" files with mvatom, too.  This is done with
the "backup" feature, where an existing destination can be renamed.

There now is a helper script: <dl> <dt> cmpanddel.sh <dd> deletes
everything from a first directory which has an indentical match in a
second directory.  It shall be safe even against the weirdest
situations where you simply cannot detect that the first directory in
fact is the second one, thus accidentally deleting a whole directory
tree.  The protection is done by renaming the source first with
mvatom.  It is not race condition free, so it is thought for all those
lazy experienced sysadmins out there who exactly know what they are
doing. </dl>
