Lf: can't move a file onto another drive

[muellerto]

The new copy implementation is a big step forwards. Also the result is shown immediately. Thanks a lot!

I detected the following bug (Windows): if I cut a single file using <d> and then I change onto another drive to paste it there using <p> I get an orange message at the bottom beginning with "rename myfilename" telling me that the system can't move the file onto another drive. Why? There's nothing special with my file, it was just the lf-zip.

When I copy or move on the same drive everything is fine.

[gokcehan]

@muellerto Thanks for reporting. This has been mentioned to me on irc as well. It is good to keep this as an issue in case we find an easy solution for this. By the way, we already mention this behavior in our recently updated documentation. Our documentation currently says:

Moving is performed using the rename operation of the underlying OS. This can fail to move files between different partitions when it needs to copy files. For these cases, users are expected to explicitly copy files and then delete the old ones manually.

I think most file managers fall back to copy-and-then-delete strategy for these cases. We can try to implement this strategy but I'm worried about a few things. Copying is a much more expensive and hairy operation which can fail in various ways. We also skip special files in our copy operations. We need to detect these errors and cancel the delete operation for these files, otherwise file loses are possible. In these scenarios, users would find some of files in the old location and some others in the new location which can be confusing. Also, currently there does not seem to be an easy way to detect different partitions. On windows, we can simply check the volume of source and destination but unix systems do not seem to have an equivalent.

[smhmd]

any updates on this?

[Limero]

I think the best solution would be to first try to move the file (with rename) and if the invalid cross-device link error is reached, then do copy-and-then-delete, if it's not possible to detect the error in advance.

An easy way to replicate this issue on Linux is to move a file from your home dir to /tmp. This causes the invalid cross-device link error on lf but works as intended on ranger.

[gokcehan]

@Limero That error invalid cross-device link is not something exported in Go standard library so there is not an easy cross-platform way to detect this error.

[gokcehan]

Marking this issue with bug label as I feel like it is important to fix this. I hope maybe with the new error handling mechanism implemented in Go 1.13, they may consider exporting a cross-device link error for the rename call. I will try to look around to see if there are other alternative solutions we can use.

[gokcehan]

I have pushed a commit to implement copy and then delete behavior. It seems to be working fine in linux and windows. I'm guessing mac and bsd should work as well though I'm not able to test it. Please report here any issues if you have.

[doronbehar]

@gokcehan I tested latest master on Linux and it seemed to work good, also noticed there's a percentage bar which is very satisfying. :clap: Thank you :heart: .

[whtv]

I think to make the behaviour more mv-like the file should be copied with cp -a. Most notably the way it is now, the moved file will have an updated mtime, which is not what you expect after moving it.