Big delete detection and --monitor rename detection seem to have failed

[MarcelRobitaille]

I just renamed a folder with 20GB of files. It got deleted from OneDrive's servers and now the client is slowly uploading them to the new location.

From what I can tell from the documentation, there should have been two mechanisms to catch this.

The first known issue says that --monitor should detect such renames and update the remote name instead of deleting and reuploading. I am using --monitor.

The option classify_as_big_delete should have prevented this deletion. I am using the default value of 1000 for this option (well, it's commented in the config file). I am using --monitor and I did not use --force.

Am I understanding the expected behaviour correctly? Should I open an issue?

[abraunegg]

@MarcelRobitaille

I just renamed a folder with 20GB of files. It got deleted from OneDrive's servers and now the client is slowly uploading them to the new location.

Renaming a folder does not trigger this catch clause.

It is interesting that a rename caused a delete and re-upload, as if the items were in-sync to begin with, initiates the rename API on OneDrive to re-name the folder on-line .... so no re-upload requried.

If you can reliably reproduce this, please open a bug report.

Additionally - from your other bug report - you are claiming you tested master .... ensure you are running 'master' please - please do not be running any earlier code as it is obsolete and unsupported.

[MarcelRobitaille]

Thanks for your response. I will try to set up a testing environment where I can reproduce this. In my real setup, it is still uploading since I renamed this yesterday.