v6: Fix database inconsistency
That could cause git-annex to get confused about whether a locked file's content was present, when the object file got touched. Unfortunately this means more work sometimes when annex.thin is set, since it has to checksum the file to tell if it's still got the right content. Had to suppress output when inAnnex calls isUnmodified, otherwise "(checksum...)" would be printed in places it ought not to be, eg "git annex get" could turn out not need to get anything, and so only display that. This commit was sponsored by Ole-Morten Duesund on Patreon.
This commit is contained in:
parent
6498643caf
commit
b2bafdb2fc
6 changed files with 76 additions and 29 deletions
|
@ -30,6 +30,30 @@ the problem yet. --[[Joey]]
|
|||
>
|
||||
> --[[Joey]]
|
||||
|
||||
> > When annex.thin is not set, inAnnex does not need to check the inode
|
||||
> > cache, and not checking it will avoid this problem.
|
||||
> >
|
||||
> > It is necessary for inAnnex to check the inode cache when annex.thin
|
||||
> > is set, because then the object file can be a hard link to the working
|
||||
> > tree and so modifiable.
|
||||
> >
|
||||
> > Checking for link count of 2 and only then checking the inode cache
|
||||
> > won't suffice though, because the object file could be modified and then the
|
||||
> > worktree file deleted, and then the object file would be modified with
|
||||
> > a link count of 1. So with annex.thin, have to always check the inode
|
||||
> > cache.
|
||||
> >
|
||||
> > So, it seems what has to be done is, when annex.thin is set, check the
|
||||
> > inode cache first, if it's unchanged great, but if not, inAnnex would
|
||||
> > need to checksum the object file to determine if it's been modified.
|
||||
> > So inAnnex gets potentially very much slower for annex.thin, but I can't
|
||||
> > see a way around that. --[[Joey]]
|
||||
|
||||
> > > Also, I was able to reproduce the repeated get, after unlock; lock;
|
||||
> > > touch; fsck and the above change did fix that.
|
||||
> > >
|
||||
> > > So, all [[done]]! --[[Joey]]
|
||||
|
||||
## more information needed
|
||||
|
||||
If gleachkr comes back to IRC, it would be good to find out:
|
||||
|
|
|
@ -24,3 +24,5 @@ lock, it does. So, here's a complete reproducer:
|
|||
git annex unlock file
|
||||
cat file
|
||||
/annex/objects/...
|
||||
|
||||
> now [[fixed|done]] --[[Joey]]
|
||||
|
|
|
@ -25,12 +25,6 @@ git-annex should use smudge/clean filters. v6 mode
|
|||
(My enhanced smudge/clean patch set also fixed this problem, in a much
|
||||
nicer way...)
|
||||
|
||||
* <http://git-annex.branchable.com/bugs/inAnnex_check_failed_repeatedly_for_present_content_v6/>
|
||||
|
||||
I have this mostly analized and need to implement the planned fix.
|
||||
|
||||
* <http://git-annex.branchable.com/bugs/>
|
||||
|
||||
## other warts
|
||||
|
||||
* There are several v6 bugs that are edge cases and
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue