Repeated "Delete operation failed" due to file not found

[JonMikelV]

Let me start by saying I understand I should be able to resolve this issue by doing a database repair. I’m posting this because I think a repair should not be necessary and am hoping somebody can explain to me why it is.

After changing my retention policy a bunch of destination files were cleaned up as they should be, however something went wrong when recording it in the local database. So now when the back runs it finishes just fine (so backups are working) but tosses out 48 sets of messages / warnings similar to the one below.

My question is, even though the delete technically failed shouldn’t we just treat it like it succeeded since the reason was that the file didn’t exist in the first place?

...
Messages: [
    removing remote file listed as Deleting: duplicati-b30479d8d2af646fbad76f4a80a704919.dblock.7z.aes,
    Listing indicates file duplicati-b30479d8d2af646fbad76f4a80a704919.dblock.7z.aes is deleted correctly,
]
...
Warnings: [
     Delete operation failed for duplicati-b30479d8d2af646fbad76f4a80a704919.dblock.7z.aes with FileNotFound, listing contents => The requested file does not exist,
...

[JonMikelV]

For the record, the database repair DID resolve the issue - but I still failing to delete a file due to it not existing should maybe be treated as a successful delete.

If the issue was actually a failure with the file LISTING and the file really did exist then it should be caught at next run as an unexpected EXTRA file and then require a database repair.

Or even better, when failed deletes are accepted as successful we store it in a log table somewhere until the next successful destination file check (then we delete the log entry).

[JonMikelV]

Just as an FYI to @kenkendk and @Pectojin I’m not the only one who has run into this issue, so it’s not just my playing fast and loose with testing that causes it.

Backup always errors, rebuild won't work to clear the error, missing file

Now I’m getting a different warning regarding deletion of files: DeletedFiles: 97 DeletedFolders: 54 ModifiedFiles: 412 ExaminedFiles: 493725 OpenedFiles: 622 AddedFiles: 210 SizeOfModifiedFiles: 1877245464 SizeOfAddedFiles: 4789971 SizeOfExaminedFiles: 312127240506 SizeOfOpenedFiles: 1896047536 NotProcessedFiles: 0 AddedFolders: 67 TooLargeFiles: 0 FilesWithError: 0 ModifiedFolders: 0 ModifiedSymlinks: 0 AddedSymlinks: 5 DeletedSymlinks: 0 PartialBackup: False Dryrun: False MainOperation: Back…

[Pectojin]

@JonMikelV

For the record, the database repair DID resolve the issue - but I still failing to delete a file due to it not existing should maybe be treated as a successful delete.

I mean, when I delete stuff from my disk and it’s not there I usually assume it worked

I’m not sure if this error is intentional but, without knowing anything about why it was implemented that way, I would agree it should be safe to silently “resolve” that issue by just accepting that the “end result” is what you wanted.

[kenkendk]

@JonMikelV

If the issue was actually a failure with the file LISTING and the file really did exist then it should be caught at next run as an unexpected EXTRA file and then require a database repair.

Or even better, when failed deletes are accepted as successful we store it in a log table somewhere until the next successful destination file check (then we delete the log entry).

Yes, so this means another log-setting: store in log, but do not report to user ?

There is already a “retention-time” on deletes because some backends report the files as present after being actually deleted, so the functionality should be as you describe.