{"action":"opened","issue":{"url":"https://api.github.com/repos/gilbertchen/duplicacy/issues/556","repository_url":"https://api.github.com/repos/gilbertchen/duplicacy","labels_url":"https://api.github.com/repos/gilbertchen/duplicacy/issues/556/labels{/name}","comments_url":"https://api.github.com/repos/gilbertchen/duplicacy/issues/556/comments","events_url":"https://api.github.com/repos/gilbertchen/duplicacy/issues/556/events","html_url":"https://github.com/gilbertchen/duplicacy/issues/556","id":433895453,"node_id":"MDU6SXNzdWU0MzM4OTU0NTM=","number":556,"title":"Duplicacy reports fossil chunk as missing immediately after resurrection","user":{"login":"Thalagyrt","id":1152333,"node_id":"MDQ6VXNlcjExNTIzMzM=","avatar_url":"https://avatars0.githubusercontent.com/u/1152333?v=4","gravatar_id":"","url":"https://api.github.com/users/Thalagyrt","html_url":"https://github.com/Thalagyrt","followers_url":"https://api.github.com/users/Thalagyrt/followers","following_url":"https://api.github.com/users/Thalagyrt/following{/other_user}","gists_url":"https://api.github.com/users/Thalagyrt/gists{/gist_id}","starred_url":"https://api.github.com/users/Thalagyrt/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Thalagyrt/subscriptions","organizations_url":"https://api.github.com/users/Thalagyrt/orgs","repos_url":"https://api.github.com/users/Thalagyrt/repos","events_url":"https://api.github.com/users/Thalagyrt/events{/privacy}","received_events_url":"https://api.github.com/users/Thalagyrt/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2019-04-16T17:17:07Z","updated_at":"2019-04-16T17:17:07Z","closed_at":null,"author_association":"NONE","body":"Hiya!\r\n\r\nI didn't see anything that seems similar in the related issues GitHub suggested looking at, so submitting this to see if you have any ideas what's up here.\r\n\r\nRunning Duplicacy 2.1.2 on kernel 4.19.33. Last night my regularly scheduled check ran, and failed with this tail end of output:\r\n\r\n```\r\nAll chunks referenced by snapshot documents at revision 853 exist\r\nFossil be95cd1b2257a89e1bdd792c7d7504186baf12ae24fe734c28c6bf507cd71724 has been resurrected\r\nChunk be95cd1b2257a89e1bdd792c7d7504186baf12ae24fe734c28c6bf507cd71724 referenced by snapshot documents at revision 854 does not exist\r\nSome chunks referenced by snapshot documents at revision 854 are missing\r\nSome chunks referenced by some snapshots do not exist in the storage\r\nSome chunks referenced by snapshot documents at revision 854 are missing\r\n```\r\n\r\nThis morning, just to sanity check, I looked for the chunk, it does exist, and `duplicacy check` is now reporting all chunks present at revision 854. I'm running check nightly immediately after my prune operation with the option to resurrect fossils: `duplicacy check -all -fossils -resurrect`\r\n\r\nIt seems to me like perhaps after the fossil was resurrected, Duplicacy checked if the fossil existed instead of the resurrected chunk somehow? This is using B2 storage so AFAIK from reading the backing code for fossilization a few months ago, it's the same object in B2, just an attribute set to hide it before deleting it permanently. Not really sure why this would break this way given that scenario. If there's any extra info I can get you I'd be glad to.\r\n\r\nIs running with `-resurrect` considered a bad idea? The docs didn't seem to indicate such, but I have a couple backup sets that run weekly which teeters on that line of when Duplicacy might consider a backup abandoned and delete chunks, so I opted to run with `-resurrect` nightly to make sure that I resurrect any fossils that are still referenced immediately after pruning.\r\n\r\nThanks for looking at this!\r\n\r\nCheers,\r\nJames"}}
{"actor":{"display_login":"Thalagyrt"}}