On 07/16/2014 10:13 AM, gregrwm wrote:
> mv will just do a rename if that succeeds, yes, but you might be
> surprised how much code mv has to massage various situations. and
> if the rename fails mv blithely barrels into copying any volume of
> data. but it looks like rename offers a more constrained
> alternative.
That's true, the reason mv(1) is a larger file than rename(1) is
precisely that mv is doing lots of safety checks that rename doesn't
perform.
However, if using mv to rename files in place, it is hard to imagine a
situation where the rename could fail beyond a disk failure that
destroys the inode tables.
The point that I would note is that the rename(1) command on most
linux distributions comes with a man-page that says:
WARNING
The renaming has no safeguards. If the user has permission
to rewrite file names, the command will perform the action without
any questions. For example, the result can be quite drastic . . .
Always make a backup before running the command, unless you know what
you are doing.
So the funny thing about that warning is that I read that as saying
"oh, a MUCH BETTER way of achieving this is to issue the following
command rather than rename: mv -b filename1 filename2"
which is renaming with a backup . . .
Of course, that does involve a call to copy. But the point remains, mv
has lots of safety checks built in, rename has none. So I'm honestly
hard pressed to think of a reason I would want to use rename over mv
when my goal is to rename files in place.