I have sys-apps/coreutils-8.32-r1, but it does not matter - busybox mv works the same way. We are in $HOME and /tmp and /home are different mounts. Try this (of course if you have no important 'b' file in home directory): $ echo a > /tmp/a $ echo b > b $ chmod 000 /tmp/a $ cat b b $ mv -f /tmp/a b mv: cannot open '/tmp/a' for reading: Permission denied $ cat b cat: b: No such file or directory $ Do you think it should work like this? Shouldn't mv command keep original destination when it can't read new data to replace its contents?
Linux kernel 5.7.0-rc2.
Same on kernel 5.5 and 5.6-pf. /tmp always on tmpfs, /home on ext4.
It is sad to read that you have problems with the software. The situation seems to be a bit more complicate and requires some analysis. We can not help you efficiently via bug tracker. The bug tracker aims rather on specific problems in .ebuilds and less on individual systems. I have had very good experience on the gentoo IRC [1] with questions like this. Of course there are also forums and mailing lists [2,3]. I hope you understand, that I will close the bug here therefore and wish you good luck on one of the mentioned channels [4]. Please reopen the ticket in order to provide an indication for an specific error in an ebuild or any gentoo related product. [1] https://www.gentoo.org/get-involved/irc-channels/ [2] https://forums.gentoo.org/ [3] https://www.gentoo.org/get-involved/mailing-lists/all-lists.html [4] https://www.gentoo.org/support/
I rather wanted to let every Linux user know, that "mv" behaves like this before they sense it on themselves. And wanted to hear if Gentoo developers = UNIX users - consider such behavior is a bug or not?
