You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are running an unattended process which uploads files from a raspberry pi. These files can become corrupt.
The corrupt files remain in the file history.
I would like to detect these corrupt file versions and remove them from the version history.
Could the family of Dropbox.file_delete* (e.g. Dropbox.files_delete_batch) support passing the file version ID? DeleteArgs I believe is passed (as opposed to the a dropbox file path), hence it maybe necessary to add another field to DeleteArgs.
It would actually be amazing these methods would also accept FileMetadata instances to save messing around extracting ids, paths etc. But that is another feature: :)
thanks.
The text was updated successfully, but these errors were encountered:
gmonkman
changed the title
Dropbox.files_delete_batch and Dropbox.files_delete to support deleting a specific version
Dropbox.files_delete_batch and similiar methods to support deleting a specific version
May 7, 2024
The Dropbox API doesn't offer this functionality, but I'll pass this along as a feature request. I can't promise if or when that might be implemented though.
We are running an unattended process which uploads files from a raspberry pi. These files can become corrupt.
The corrupt files remain in the file history.
I would like to detect these corrupt file versions and remove them from the version history.
Could the family of Dropbox.file_delete* (e.g. Dropbox.files_delete_batch) support passing the file version ID? DeleteArgs I believe is passed (as opposed to the a dropbox file path), hence it maybe necessary to add another field to DeleteArgs.
It would actually be amazing these methods would also accept FileMetadata instances to save messing around extracting ids, paths etc. But that is another feature: :)
thanks.
The text was updated successfully, but these errors were encountered: