Attempt copy+remove if permission denied when moving file

[Limero]

I mount my server to my workstation with sshfs and noticed when attempting to move a file across devices on the same mount, a permission denied error is given, not a cross device error.

Error:

mv: cannot move 'test' to 'usbhd/test': Operation not permitted

How I reproduce it:

1. On the server, a separate hard drive is mounted to ~/usbhd
2. The home dir on the server is mounted on my workstation at /tmp/nuc
3. Navigate with lf to /tmp/nuc and try to move anything between home directory and the mounted disk

This PR makes the move function treat a "permission denied" error the same way as a "cross device" error. This allows me to freely move files between devices over sshfs.

I'm not sure if always attempting a copy on "permission denied" errors could cause any separate issues, but I noticed when attempting to move files owned by root, that gave me an access error (EACCES) instead.

[gokcehan]

@Limero I'm not sure if it is a good idea to fall back to copy+remove in all permission denied errors. In most cases except maybe this one, I expect copy+remove to also fail after copying when there is a permission denied error.

[Limero]

@gokcehan Yeah, I agree it's not optimal, but I can't think of a better solution in this case. My thinking is, in normal cases it shouldn't matter if it fails on the move or the copy+remove, so might as well attempt it when there is a possibility that it works.

In ranger, I can move files freely between these directories, but after having a quick look through their code, it seems to be because they always do copy+remove when moving things.

[Limero]

@gokcehan Is there any additional changes I can do for you to be ok with merging this? How about if I make it an option toggled in settings, so it doesn't affect everyone unless you specifically set it?

[gokcehan]

@Limero I still think this is a poor workaround for a niche use case as nobody else showed explicit interest in this PR so far, but I guess I wouldn't mind if this was added as an option. I was wondering, what does mv do in this case? Also, did you try playing with the mount options to see if it makes a difference?

[joelim-work]

@Limero Have you tried adding -o workaround=renamexdev when using sshfs? I could reproduce the issue using the above steps, but adding that option fixed it for me. If it works for you too, then you can update the integration in the wiki.

[Limero]

@joelim-work That fixed it, thank you! I've updated the wiki to mention the fix