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

meh

Browse source
This commit is contained in:
Joey Hess 2020-06-17 15:50:55 -04:00
parent 762fd5ae5d
commit 3464fa12c7
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 33 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
doc/bugs/one_annex_test_FAILs_when_HOME_is_a_crippled_fs.mdwn
View file

@ -54,7 +54,3 @@ git annex is 8.20200522+git142-g9102d3172-1~ndall and .deb available within the
details of the setup are [in that PR](https://github.com/datalad/datalad-extensions/pull/15/files#diff-8364c688b76bfaf5df947cfd4d74eef7R76)
PS determining the boundaries and names of the tests git annex had ran is a tricky business on its own -- I wondered if tests output formatting and annotation could have been improved as well. E.g. unlikely there is a point to print all output if test passes. With `nose` in Python / datalad we get a summary of all failed tests (and what was output when they were ran) at the end of the full sweep. That helps to avoid needing to search the entire long list
> I've fixed two tests now, so [[done]]. (Also git-annex test succeeded
> on vfat.) --[[Joey]]

33
doc/bugs/one_annex_test_FAILs_when_HOME_is_a_crippled_fs/comment_10_0b41fe04a5d820dbb17412eaa2ea8760._comment Normal file
View file

@ -0,0 +1,33 @@
[[!comment format=mdwn
username="joey"
subject="""comment 10"""
date="2020-06-17T19:41:29Z"
content="""
Hmm, implemented all that, it did fix my shell test case.
But, the test suite is still hanging in the same place when run on vfat.
stracing the git-annex smudge command that is hung:
fcntl(0, F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}
fd 0 is .git/annex/gitqueue.lck
So hmm, this seems like a different problem than the one I fixed.
It's not involving pid locking.
The parent git-annex also has the same lock file open, and presumably
locked exclusively. So it makes sense it would deadlock, both the parent
and child trying to lock the same lock. It's kind of odd that this only
happens on vfat. I don't think this is because of vfat's limitations
though. It's a legitimate deadlock.
I get the feeling that gitAnnexGitQueueLock needs to be taken in a more
fine-grained way. Or Annex.Link should not be using the git queue
for what it does, which is not really a queue in the same way Git.Queue is
usually used. If Annex.Link instead deferred the action until cleanup in
some other way, it would not take gitAnnexGitQueueLock and so when it runs
smudge it would not matter if that did take the lock.
Unfortunately I'm out of time to fix it before today's planned release.
"""]]