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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
