mv: fails to create dir when missing read permissions

When moving a dir to a different filesystem, GNU mv first creates a new dir, and then bails out, leaving behind an empty dir:

$ rm -rf /tmp/foobar/ && mv -v /root/ /tmp/foobar
created directory '/tmp/foobar'
mv: cannot access '/root/': Permission denied
[$? = 1]
$ file /tmp/foobar
/tmp/foobar: directory

We currently don't:

$ rm -rf /tmp/foobar/ && cargo run -q --features mv mv -v /root/ /tmp/foobar
mv: Permission denied
[$? = 1]
$ file /tmp/foobar
/tmp/foobar: cannot open `/tmp/foobar' (No such file or directory)

Found while reviewing #6632.

Also: That error message is uninformative. Which permission was denied? When accessing which file? Is the permission problem with the source or with the destination? I hope you can see how this error message might be confusing when there's many files being moved/copied. However, this might be fixed by #6632.

Reproduce the cross-filesystem move with cargo run -q --features mv mv -v /root/ /tmp/foobar, then compare it with GNU mv. Start by tracing the mv command's handling of directory creation and permission errors, and review issue #6632. Done means the failed move does not leave an empty destination directory and reports which access failed, if that is not already covered by #6632.