Missing chunk and .tmp files

Hi there,

I have a short question. Using duplicacy now produces some warnings about missing chunks. So I started checking against the list (Fix missing chunks) and found my missing chunk files. But I am not sure what happened here. So maybe someone knows this scenario?


2022-03-29 11:15:53.322 WARN SNAPSHOT_VALIDATE Chunk 451a0283614da4b29b3b8cdcbcf2313fc6d7e67a85bb364e94ceea8e6592a7f9 referenced by snapshot opt_backup at revision 22 does not exist

I found this file in the folder 45 but it was not named as expected:


It is 16MB of size which is one of the larger chunks, but at the moment if have no clue if this file is corrupt or correct. Is anyone knowing what happened here?

For more details:
I am using the pcloudcc tool to mount my pcloud drive. Duplicacy is then configured to use this local folder. Tried to search for ‘ocefullg’ but it seems to be some randome stuff as I am having 12 such files. All I found was this line which in my eyes can causes exact this behaviour:

Any idea what happened? Maybe it has something to do with a mounted drive?
(At the moment I add the mounted drive in my duplicacy docker container which is working very well. But now I switched back and run it local since this error happened.)

Thx for your help

Do you have prune scheduled?

Interrupted prune leaves ghost snapshots that were supposed to be deleted but because prune was interrupted they stayed. Those snapshots reference a bunch of already deleted chunks and will keep failing check.

This is the only way I have ever ended up with check failures myself. As a result I stopped pruning altogether.

To recover — run check with persist, find all bad snapshots, delete them manually from snapshots folder, and purge local cache

1 Like

I have prune active. This is my schedule (both checks are telling missing chunkgs):
(At the momenta I run check with: -a -files -chunks -fossils -threads 4)

I’m not sure what’s the benefit or running -check with chunks let alone files, but please do try the approach suggested above to get rid of ghost snapshots.

You can actually confirm that those are indeed the ghost snapshots (and it’s the only failure mode you are seeing) by looking for prune logs that have “deleted” the snapshots in question. Note: that log message is a lie, while it says “snapshot deleted” it’s just collected for deletion later; and if that later never happens – the snapshot physically stays.

I believe this is a pcloudcc issue. If the rename operation isn’t detected by pcloudcc or if it doesn’t process it properly, then you will see these files. You can manually rename them to the correct names.

Ok I renamed them and run a check now. Thx for your help!

They should be okay but you can always make sure by running a check job with -chunks (after manually renaming those files).