mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions 1

Added a comment

Browse source
This commit is contained in:
Atemu 2021-06-29 22:57:39 +00:00 • committed by admin
parent d9949944d1
commit 99266d7875
1 changed files with 52 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

52
doc/bugs/Git_repos_corrupt_themselves/comment_17_faaa433ba8df649771469fdbcd9bb69e._comment Normal file
View file

@ -0,0 +1,52 @@
[[!comment format=mdwn
username="Atemu"
avatar="http://cdn.libravatar.org/avatar/d1f0f4275931c552403f4c6707bead7a"
subject="comment 17"
date="2021-06-29T22:57:39Z"
content="""
Hi Joey, thank you for looking into this again.
> It's odd that log shows a second fsck run after the repair was already triggered. I do not see a way that this would happen unless fscks are scheduled very close together.)
Note that I started the assistant again in that log. The consistency check didn't finish the first time because somehow corruption was detected and the assistant crashed itself in trying to repair (I didn't accept any repair prompts in the GUI that time IIRC).
AFAICT the consistency check is what triggers the issue because, since turning it off (and creating new repos on my clients), I haven't experienced a single repo corruption.
The schedule was set to whatever the assistant nudges you to set by default.
> comment 14
That sounds a lot more sane.
Perhaps the repair functionality could use a complete overhaul. I've also found it to be extremely slow compared to simply copying missing or corrupt objects/packs from another remote.
Ideally it should be able to restore a git repo to a working state without .git/objects present at all as it should only needs remotes and refs.
Extracting objects from the corrupt objects dir which aren't in any remote should be done if possible though because important local-only objects are a thing (stashes, additional branches, branches that are ahead of the remote's)
> Removing repair from the assistant (and git-annex repair) should be on the table as a solution to this.
Manual repair and detection can stay IMO but any *automatic* repair needs to go entirely or be optional.
> Removing repair from the assistant (and git-annex repair) should be on the table as a solution to this. It's a whole lot of complexity that might fix a few user's repos sometimes, but is outside of git-annex's scope and is mostly only used by assistant users.
I've actually (tried) using it from the CLI too, having it as an option there would be useful.
I agree that it's out of scope though. It would probably be better off as a separate project as it's useful in any git repo, not just git-annex ones. Some integration with git-annex would be appreciated though.
Perhaps this functionality could be fully spun out into git-repair which could then become an optional add-on to git-annex.
> Was the assistant interrupted somehow while it was running repair, in Atemu's case?
The laptop being powered off etc. was not the case. Though I do shut down the daemon quite often because of https://git-annex.branchable.com/bugs/OSX__58___Pushed_changes_are_autocommited/ (via the GUI or --stop). Do the shutdown and restart procedures check for a running repair?
I also sometimes had to kill all git processes for one reason or another but I don't think that ever happened after I pressed the repair button (I wait that out for good reason).
***
So current issues distilled from this thread so far:
* The scheduled consistency check can trigger automatic(!) repairs and even do so erroneously
* This repair procedure does something destructive without a prompt
* Applying the destructive repair to a working repo corrupts it
* Repair can't actually repair the mishap despite all the data being available
* Repair would probably be better off as a dedicated project outside of git-annex
"""]]