Recursive deletion with retention policy not working

[ksavin]

Hello.

It seems that the fix applied in #955 does not work for me. I haven't found any relevant config settings to enable it and it looks like the code only checks that the account is not personal and that error message matches. I'm likely missing something here, hence, not submitting to the bug tracker.

Extract from log onedrive --synchronize --upload-only --verbose --verbose
Running on empty folder to clear personal sharepoint. Any remotely sensitive info is replaced with xxx.

[DEBUG] skip_dir evaluation for: Work
[DEBUG] No Strict Matching Enforced
The directory has been deleted locally
Deleting item from OneDrive: Work
[DEBUG] Number of items to delete: 93
[DEBUG] Attempting to delete item from drive: xxx
[DEBUG] Attempting to delete this item id: xxx
OneDrive returned a 'HTTP 403 - Forbidden' - gracefully handling error
[DEBUG] onedrive.deleteById generated a 403 error response when attempting to delete object by item id
[DEBUG] Attemtping a reverse delete of all child objects from OneDrive
[DEBUG] Delete child item from drive: xxx
[DEBUG] Delete this child item id: xxx
OneDrive returned a 'HTTP 403 - Forbidden' - gracefully handling error
[DEBUG] A further error was generated when attempting a reverse delete of objects from OneDrive

ERROR: Microsoft OneDrive API returned an error with the following message:
  Error Message:    HTTP request returned status code 403 (Forbidden)
[DEBUG] Raw Error Data: HTTP request returned status code 403 (Forbidden)
{
    "error": {
        "code": "accessDenied",
        "innerError": {
            "client-request-id": "xxx",
            "date": "2021-06-24T23:16:18",
            "request-id": "xxx"
        },
        "message": "Request was cancelled by event received. If attempting to delete a non-empty folder, it's possible that it's on hold"
    }
}
[DEBUG] JSON Message: {"error":{"code":"accessDenied","innerError":{"client-request-id":"xxx","date":"2021-06-24T23:16:18","request-id":"xxx"},"message":"Request was cancelled by event received. If attempting to delete a non-empty folder, it's possible that it's on hold"}}
  Error Reason:     Request was cancelled by event received. If attempting to delete a non-empty folder, it's possible that it's on hold
  Error Timestamp:  2021-06-24T23:16:18
  API Request ID:   xxx
  Calling Function: uploadDeleteItem()

Uploading new items of /home/ksavin/OD
[DEBUG] ################################################ SYNC COMPLETE ###############################################
[DEBUG] Merge contents of WAL and SHM files into main database file

OS: Linux pc33548 5.10.42-1-MANJARO #1 SMP PREEMPT Thu Jun 3 14:37:11 UTC 2021 x86_64 GNU/Linux
GUI: XFCE
Account type: business
Source/Package: built from source
DMD version: DMD64 D Compiler v2.097.0
OneDrive version: onedrive v2.4.12-10-g13b3709
Config:

onedrive --display-config
Configuration file successfully loaded
config file has been updated, checking if --resync needed
onedrive version                       = v2.4.12-10-g13b3709
Config path                            = /home/ksavin/.config/onedrive
Config file found in config path       = true
Config option 'check_nosync'           = false
Config option 'sync_dir'               = /home/ksavin/OD
Config option 'skip_dir'               = 
Config option 'skip_file'              = ~*|.~*|*.tmp
Config option 'skip_dotfiles'          = false
Config option 'skip_symlinks'          = false
Config option 'monitor_interval'       = 300
Config option 'min_notify_changes'     = 5
Config option 'log_dir'                = /var/log/onedrive/
Config option 'classify_as_big_delete' = 1000
Config option 'upload_only'            = false
Config option 'no_remote_delete'       = false
Config option 'remove_source_files'    = false
Config option 'sync_root_files'        = false
Selective sync 'sync_list' configured  = false
Business Shared Folders configured     = false

curl:

curl 7.71.1 (x86_64-conda_cos6-linux-gnu) libcurl/7.71.1 OpenSSL/1.1.1k zlib/1.2.11 libssh2/1.9.0
Release-Date: 2020-07-01
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS GSS-API HTTPS-proxy IPv6 Kerberos Largefile libz NTLM NTLM_WB SPNEGO SSL TLS-SRP UnixSockets

sync_dir type: local
filesystem type: ext4
Folder is not shared with dual-boot Windows. One-drive account is used in both windows and linux.

[abraunegg]

@ksavin
Please submit a bug report + ensure you provide non-redacted verbose debug logs via the support email address so that this can be analysed to understand what exactly is going on.

As I am 100% unable to ever reproduce this issue due to the required Azure AD security configurations needed to implement retention policies, it could be that the prior 'fix' might only be partial, thus, may need additional work.

[abraunegg]

@ksavin

onedrive --synchronize --upload-only --verbose --verbose

Additionally - thinking on this a little further based on how you are running the application.

With --upload-only you are only uploading data, but not telling the client about any other file that might reside in that location.

So when deleting files, the client will only delete files that it knows about. If there are other files that are present online, that you (or other folk) have uploaded to that location, then, these are not known about the client you are running, thus, will still remain when you are attempting to delete the folder.

There are a few options here:

• Dont use --upload-only so that the client knows the full state of all files online .. this might not be desirable in your scenario
• When a further 403 error is returned, query the OneDrive API for the object that failed to delete to obtain the children of that object, then delete all those children, even though the client itself does not know about it
  • This could also lead to undesirable data loss if you are deleting then files that are not yours, that other folk uploaded - your client does not know about those files .. but you are forcing the delete of them via the API

Again, as I am 100% unable to ever reproduce this issue due to the required Azure AD security configurations needed to implement retention policies, if any development work is to be done, this would require interaction and testing from you on each PR commit to assist with it's development.

[ksavin]

Additionally - thinking on this a little further based on how you are running the application.

That's it! My assumption was that --upload-only queries directory graph in order to circumvent retention policies, i.e. delete from graph nodes up to parent directory. Logs say that it tries deleting parent directory right away.
Synchronized test folder (with nested contents) without --upload-only, deleted parent folder and synchronized with --upload-only. It worked. Much appreciated.

When a further 403 error is returned, query the OneDrive API for the object that failed to delete to obtain the children of that object, then delete all those children, even though the client itself does not know about it

Does --dry-run queries file structure without uploading or downloading?

Again, as I am 100% unable to ever reproduce this issue due to the required Azure AD security configurations needed to implement retention policies

And I apologize for being reluctant to share unedited logs with you. Now that we know the cause, I hope it is no longer necessary.

[abraunegg]

@ksavin

Does --dry-run queries file structure without uploading or downloading?

Yes, but deletes (local -> remote) it assumes success - it is not passing the action to OneDrive to get a result, thus, retention policy blocking action will not be picked up.

And I apologize for being reluctant to share unedited logs with you. Now that we know the cause, I hope it is no longer necessary.

If you want this to be fixed, a bug log needs to be filed + you need to make the commitment to test any PR that is developed. I cannot test this.