mv command implicitely copies files
Hello
I hate the behaviour of the mv command to make copies if it can't
move a file. There should at least be options to switch this off (so
I could alias it in my shell startup files with those options on).
It would be ok to copy a file if it *can* remove the file from the
old place (and it *can* check the permissions to find that out). In
some cases that will lead to different permissions on the new file,
though; so this needs a second switch.
Here's an example to show what I mean:
root$ cd /tmp
root$ echo Hello > world
root$ su someuser
someuser> /bin/mv world myworld
/bin/mv: cannot unlink `world': Operation not permitted
/bin/mv: cannot remove `world': Operation not permitted
someuser> ls -lrt
-rw-r--r-- 1 root root 6 Sep 18 14:37 world
-rw-r--r-- 1 someuser someuser 6 Sep 18 14:37 myworld
What do others think about that? Why do we still have a tool that
doesn't work as expected (and can't be configured to work so)?
If noone else does, I would even code it.
Note that mv on HP-UX (imadev B.10.20 A 9000/715 2009123119 two-user
license) works IMHO correctly:
# su someuser -c 'mv world myworld'
mv: myworld: rename: Not owner
Don't tell me that I "shouldn't" mv files that I don't own or some
such. Frequently one doesn't know when one owns a file, like in batch
processing. Everything that's needed to work around it is just a
kludge.
mv should move and not copy things, except if it has to copy them
over a filesystem boundary (or, and preferably only at user's
request, if it can move it with the result of changed permissions).
Cheers
Christian.
Reply to: