Interactive directory move that defaults back to file move server side because directory already exists google drive. doesn't work

[left1000]

I found that in an outdated version of rclone an interactive directory move I tried that had to default back to a file move server side because the directory already existed didn’t work.

Details:
The remote is google drive and the source folder has 10k-40k files and the destination folder has 200-300k files and yes the folders both exist due to a capitalization error that is my own fault.

And so. Using rclone 1.63 and the command
.\rclone move -vv --interactive "remote:D:\folder" "remote:D:\Folder"

This process after a few y yes results in listing all the transfers that need to be made and then hangs. No feedback.

Then.
Using rclone 1.72.1 and command
.\rclone move -vvv "remote:D:\folder" "remote:D:\Folder"

Everything works perfectly.

Now either this is a bug that was fixed during the many releases between the two folders I tried this command with, OR this is a bug where-in interactive directory server side transfers get confused when they need to ask for per file move y yes responses. Confused in such a way that they never allow or ask for said y to be input. My guess being that rclone is defaulting to doing per file server side transfers, but the interactive layer of rclone wants to be interactively discussing directories not files? That’s just my wild guess though, and it may very well already be fixed. I’ll have to see if the issue arises again. And yes, I was using a wildly outdated version of rclone. I had the newer version downloaded and in a folder right next to the old one, so I thought I was using the right one, but I had left the default terminal folder as the old rclone instead of the new one. Whoops. Many user mistakes in this post, hence why I only suspect a bug

I can’t repeat the test really because everything is perfect now. A test with a dozen dummy folders or files wouldn’t be a true repeated test because the quantity may have been the cause of rclone’s issues in my above example.

edit:
TLDR: I have no way of knowing if using the proper version of rclone fixed my issues OR if removing the interactive flag is what helped in this case, since I changed two things at once I can’t know which mattered.

EDIT2: I repeated the test successfully by finding another smaller disorganization flaw I made.

This time I am using interactive in 1.72 so if it does not work, then there is a bug.

Aaaaaaaaaand the issue reoccured! BUUUUUUUUT I figured out a work around. If you just start randomly typing y and pressing enter it works!

[left1000]

Okay, at least on google drive if you run the command, while the target directory exists forcing rclone to abandon the directory serverside move AFTER you’ve said y yes to it once, and relying on file by file moves…

.\rclone move -vvv --interactive "remote:D:\Folder" "remote:D:\OtherFolder"

You will get the chance to hit y for yes once. Then rclone will appear to freeze, but what in fact has happened is that the command line GUI is what is confused. So hitting y enter or ! enter can unstick this issue.

In other words the progress status update is appearing instead of future interactive prompts, making the user confused.

You have to just by psychic and use the mystical powers of the force to guess when to type y enter or ! enter. If you do guess properly everything works.

I’d call this a bug, but not one that really needs to be fixed…. maybe a warning about how mixing these types of choices will result in funky behavior on the docs wiki would be enough?

EDIT: Note while I originally noticed this behavior on wildly out of date rclone I recreated the issue on up to date 1.72.1 the first test was 40000 files and the second test was more like 2000 files but that doesn’t really effect what is more of a user interface glitch than a true bug.