Auto trash clearing recognition while file uploads are in progress

I have the premium feature for auto trash clearing turned on for immediate clearing (and I am a premium user).
I have noticed that while uploads are in progress, any files that are deleted from a synced folder during this time are not recognised until after all uploads are finished. It would be great if file deletions could be recognised and synced sooner.
This is my use case:
I create system backups using Macrium. These backups are synced with odrive to my cloud storage. The backup folder is synced using the sync to odrive premium feature.
Backup retention policies on Macrium will delete old backups after creation of new ones. I have the retention policies set such that I never have more than 1 TB of backups in total which will keep the total below the limit of my OD4B cloud storage.
Once the backups are created , odrive immediately starts syncing the backup files and then within a few seconds Macrium will delete old backup files but odrive does not recognise these deletions until it has finished uploading all of the new backups. This creates the possibility that I could run out of cloud storage space before the old backups are deleted in cloud storage.

This scenario has not yet happened and it may be the case that if I do run out of storage then syncing will stop, the deletes will be seen by odrive and deleted from cloud and then syncing will restart again. If this is the case (is it?) then it may only be an inconvenience of interrupted uploads. If not, then the feature request may be useful.


Hey @sean,
This is a tricky one.

During the upload the folder path is basically “locked” to keep the states consistent between the various threads that are acting on it. We probably don’t want to change this behavior, but we can look at proactively querying for drive quota for large file uploads for sources that support it (something that would be a good idea anyway).

The expected behavior is as you stated, where the upload will fail and then retry later. At that point the delete will have been processed, freeing up the needed space. It would be more optimal to fail the upload before it starts, rather than waiting until an exception is hit on upload commit.

I actually need to check on what the OD4B behavior is when you try to upload a file without enough quota in the drive. They have an opportunity to reject the upload initialization, but I’m not sure if they do. If they do then the behavior should already be optimized.