Prune fails on message about existing fossil

Granite · 10 June 2023 00:02

On google drive (workspaces) I was running a large prune -exhaustive job that was going to take weeks (I deleted snapshots from a computer I no longer need), so I cancelled it and set it up with more threads. However, I started getting error messages. After searching the forums, I thought it could be caused by my outdated GUI install or cancelling the original prune job. So, I updated the program and ran a check command with resurrect fossils. I then successfully ran another prune -exhaustive. A week later, it’s time to delete the collected fossils, but my prune command failed with the same error messages as before. These are the same type of messages that was causing the fail the first time. I checked my folder, and the file does exist in the fossils folder. I wonder what I should try next? Thanks!

2023-06-09 00:43:35.283 ERROR DOWNLOAD_CHUNK Failed to download the chunk 774c3bd33835d2d37ac7d92450b2b4ad03022f5f9f4ce15e32a076426041baf7: chunks/77/4c3bd33835d2d37ac7d92450b2b4ad03022f5f9f4ce15e32a076426041baf7.fsl does not exist
Failed to download the chunk 774c3bd33835d2d37ac7d92450b2b4ad03022f5f9f4ce15e32a076426041baf7: chunks/77/4c3bd33835d2d37ac7d92450b2b4ad03022f5f9f4ce15e32a076426041baf7.fsl does not exist

Related Threads

saspus · 10 June 2023 01:31

If the file exists but duplicacy thinks it does not — maybe there are some failures related to rate limiting.

Reduce number of threads to no more than 4, that was shown to work. Anything more you are risking rate limiting, and perhaps some failures that are not properly handled and end up in misleading “file not found” reported.

Pruning google drive can take a very long time (weeks). I would suggest run it in one thread from some cloud instance so you don’t have to keep your machine powered for so long.

Granite · 10 June 2023 19:23

Thanks for your feedback. I am using an always on computer so only power outages or ISP issues will interfere (which aren’t common but do happen from time to time).

I had reduced down to 4 threads already, so I tried with one thread and it still chokes on the same fossil file. I did double check again it was in the fossils folder. It’s 156 KB and created June 1. I tried running with debug turned on but it didn’t seem to show anything much more. Here are the two lines that proceed the same messages as my first post when I run the debug:

2023-06-10 00:44:43.682 DEBUG CHUNK_CACHE Chunk 43b22a040e2a1205487b4ad9c3eb817d2efcdda5edaf995648f562316c7ff079 has been loaded from the snapshot cache
2023-06-10 00:44:44.620 INFO PRUNE_NEWSNAPSHOT Snapshot JOHNHP2022 revision 4798 was created after collection 1

and then the next message is about the same fossil failing to download.

Edit:

One of my other computers runs a routine check and it is failing there as well:

2023-06-10 10:26:09.354 INFO SNAPSHOT_CHECK All chunks referenced by snapshot JOHN HP2022 at revision 4796 exist
2023-06-10 10:26:09.556 INFO SNAPSHOT_CHECK All chunks referenced by snapshot JOHNHP2022 at revision 4797 exist
2023-06-10 10:26:10.058 WARN DOWNLOAD_FOSSIL Chunk 774c3bd33835d2d37ac7d92450b2b4ad03022f5f9f4ce15e32a076426041baf7 is a fossil
2023-06-10 10:26:10.230 ERROR DOWNLOAD_CHUNK Failed to download the chunk 774c3bd33835d2d37ac7d92450b2b4ad03022f5f9f4ce15e32a076426041baf7: chunks/77/4c3bd33835d2d37ac7d92450b2b4ad03022f5f9f4ce15e32a076426041baf7.fsl does not exist
Failed to download the chunk 774c3bd33835d2d37ac7d92450b2b4ad03022f5f9f4ce15e32a076426041baf7: chunks/77/4c3bd33835d2d37ac7d92450b2b4ad03022f5f9f4ce15e32a076426041baf7.fsl does not exist

sigh I just realized the check command referenced above has been running on a schedule daily with resurrect fossils on.

Edit:

I ran the check command with persist. I wonder if I should delete the revision in question and see what happens?

2023-06-10 16:16:03.677 INFO SNAPSHOT_CHECK All chunks referenced by snapshot JOHNHP2022 at revision 4797 exist
2023-06-10 16:16:04.134 WARN DOWNLOAD_FOSSIL Chunk 774c3bd33835d2d37ac7d92450b2b4ad03022f5f9f4ce15e32a076426041baf7 is a fossil
2023-06-10 16:16:04.253 WARN DOWNLOAD_CHUNK Failed to download the chunk 774c3bd33835d2d37ac7d92450b2b4ad03022f5f9f4ce15e32a076426041baf7: chunks/77/4c3bd33835d2d37ac7d92450b2b4ad03022f5f9f4ce15e32a076426041baf7.fsl does not exist
2023-06-10 16:16:04.526 WARN DOWNLOAD_FOSSIL Chunk 168b563b0c41d1ec4d46883a7b0cda03e94a5a053d2699b1937dc55b8f7418b9 is a fossil
2023-06-10 16:16:04.648 WARN DOWNLOAD_CHUNK Failed to download the chunk 168b563b0c41d1ec4d46883a7b0cda03e94a5a053d2699b1937dc55b8f7418b9: chunks/16/8b563b0c41d1ec4d46883a7b0cda03e94a5a053d2699b1937dc55b8f7418b9.fsl does not exist
2023-06-10 16:16:04.898 WARN DOWNLOAD_FOSSIL Chunk 855315d23e0fe1e78b296b034952fdb0dea4b49ce40a764525f49a37ee8007ed is a fossil
2023-06-10 16:16:05.031 WARN DOWNLOAD_CHUNK Failed to download the chunk 855315d23e0fe1e78b296b034952fdb0dea4b49ce40a764525f49a37ee8007ed: chunks/85/5315d23e0fe1e78b296b034952fdb0dea4b49ce40a764525f49a37ee8007ed.fsl does not exist
2023-06-10 16:16:05.292 WARN DOWNLOAD_FOSSIL Chunk c9ba6f1b741b980b513ff17934ad2012fb60e1a4c560d690001472619e28dfda is a fossil
2023-06-10 16:16:05.402 WARN DOWNLOAD_CHUNK Failed to download the chunk c9ba6f1b741b980b513ff17934ad2012fb60e1a4c560d690001472619e28dfda: chunks/c9/ba6f1b741b980b513ff17934ad2012fb60e1a4c560d690001472619e28dfda.fsl does not exist
2023-06-10 16:16:05.409 ERROR SNAPSHOT_CHUNK Failed to load chunks for snapshot JOHNHP2022 at revision 4798: invalid character ‘f’ after top-level value
Failed to load chunks for snapshot FrancesHP2022 at revision 4798: invalid character ‘f’ after top-level value

saspus · 10 June 2023 21:58

!!! Nice catch! There was some fierce competition for the chunk fossils going on

You can run check with -fossils but without -resurrect. This will take care of finding fossilized chunks that are going to be deleted but haven’t been yet, without actually resurrecting them.

If that revision was supposed to be pruned away — then yes, delete it. But doing so will leave a lot of orphaned chunks. You can follow up with -exhaustive prune to clean them up.

If you want to immediately clear up the datastore — then ensure no other instance is touching the datastore and add -exclusive flag to prune. This will run without any concurrency safety so make sure all other duplicacy processes that can touch the same datastore definitely cannot run.

I’m not sure what this means, never seen this before.

Granite · 11 June 2023 00:23

I saw no harm in artificially pruning that one. It’s on a computer with 2 hour snapshots with little change between the snap shots unless a bunch of photos were pushed to it.

So after deleting 4798 I ran a check which was unhappy, but it became happy when I added -fossils (no resurrect this time!). It did find some fossils attached to existing snapshots, but not the problematic one. But all the fossils found were in the same snapshot ID. (About 20 fossils total).

I’m happy to say I’m about 2 hours into a prune job and it’s going well. Before it was failing in about 20 minutes when it had issues with that chunk attached to revision 4798. Something went wrong but I couldn’t tell you what. The file is encrypted so it was just gibberish in notepad. I’m not a programmer but my guess is something went wrong with either the fossil or that snapshot. It’s hard to say if it’s related to the prune or or maybe just bad timing when the power flickered a week ago.

Does resurrect only affect existing snapshots? If so, my prune -exhaustive from last week might still be successful in catching all the pieces I wanted gone from the computer I removed. Fingers crossed and thanks for your help! I will report back if I have any issues. If nothing else I have a deeper understanding of the two-step fossil collection and deletion!