Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

forget reports that files have been deleted when they can't be #5140

Open
colans opened this issue Nov 14, 2024 · 4 comments · May be fixed by #5179
Open

forget reports that files have been deleted when they can't be #5140

colans opened this issue Nov 14, 2024 · 4 comments · May be fixed by #5179

Comments

@colans
Copy link

colans commented Nov 14, 2024

Output of restic version

  • restic 0.17.0 compiled with go1.23rc2 on linux/amd64

What backend/service did you use to store the repository?

BackUpscale

Problem description / Steps to reproduce

When running in append-only mode, snapshots can't be deleted. However, restic forget reports that they have been, even though they haven't.

Expected behavior

Shouldn't the last line here say that "0 / 1" files have been deleted?

repository 19897fd5 opened (version 2, compression level auto)
Remove(<snapshot/2eccde165a>) failed: unexpected HTTP response (403): 403 Forbidden
unable to remove snapshot/2eccde165a030dc068e4ec4a092e47da136f0baeb98313925e562f5c095b91fa from the repository
[0:00] 100.00%  0 / 1 files deleted

Actual behavior

Instead, the last line says, "1 / 1 files deleted". So why it saying something was deleted when it wasn't? Earlier in the output it says "Forbidden" and the snapshot is still there. This is a UX hit because users will think that it's actually happening, when it can't be. And then we all start getting more support requests. :)

repository 19897fd5 opened (version 2, compression level auto)
Remove(<snapshot/2eccde165a>) failed: unexpected HTTP response (403): 403 Forbidden
unable to remove snapshot/2eccde165a030dc068e4ec4a092e47da136f0baeb98313925e562f5c095b91fa from the repository
[0:00] 100.00%  1 / 1 files deleted

Do you have any idea what may have caused this?

My guess is that it's reporting that number of things that are supposed to be deleted as per the user request, not the number of things that actually have been deleted after the request has been processed.

Did restic help you today? Did it make you happy in any way?

If it weren't for Restic, I wouldn't be able to work on BackUpScale! So thank you all!!

@konidev20 konidev20 linked a pull request Dec 15, 2024 that will close this issue
4 tasks
@konidev20
Copy link
Contributor

@colans I found the issue. The progress printer was absorbing the error before the progress counter checked for an error and incremented the counter.

You can take a local build of my branch from #5179 and see if it works as expected.

@colans
Copy link
Author

colans commented Dec 18, 2024

@konidev20 Thanks! Not sure I'm going to be able to test right away. Any chance you could add tests? This is required for the MR to be merged anyway.

@konidev20
Copy link
Contributor

konidev20 commented Dec 18, 2024

Hey @colans,

I have started to add a few tests, will complete it over the next weekend.

@konidev20
Copy link
Contributor

I have added the tests. Seems to be working fine. Please check it out in your free time @colans

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants