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

comment

Browse source
This commit is contained in:
Joey Hess 2024-10-21 11:24:50 -04:00
parent 98ad05a07b
commit 952442fdc4
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 35 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

35
doc/bugs/git-annex_proceeds_forward_if_freeze_script_fails/comment_1_04b8a3aa55628e7fe41a871f14121c92._comment Normal file
View file

@ -0,0 +1,35 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2024-10-21T14:49:49Z"
content="""
Given the number of different ways freezeContent is called, it would be
very difficult to implement error unwinding for it. So a failure would
leave things in a potentially unusual state. For example a failure during
`git-annex add` at one point would leave the file moved into the
repository, but without an annex symlink pointing to it.
Or in some cases, freezeContent is the last thing that is done, so failing
would leave it in the same state as not failing.
Looking at this another way, there are two ways a freezecontent hook can
fail:
1. It exists successfully, but has not actually managed to freeze the
content.
2. It exits nonzero.
git-annex cannot detect the first case. So there does not seem to be much
benefit to complicating git-annex to detect the second case and handle it
specially.
Regular lock down of files by removing permissions can also fail, in an
expected way, in a shared repository when the "wrong" user is running
git-annex . `git-annex fsck` deals with that by trying again to freeze the
content and checking if the file has the desired permission, and warning if
not.
Since fsck does run the freeze hook, it will display those error messages
again, which at least will remind the user that the hook is broken. And if
they fix it, fsck will freeze the content.
"""]]