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

close keys db to possibly work around WSL1 issue

Browse source
This commit is contained in:
Joey Hess 2021-10-19 13:07:49 -04:00
parent 67a67d740b
commit 0f38ad9a69
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 32 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

25
doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_6_b7a3837fd6af236e9ecf6d5bae077fd0._comment Normal file
View file

@ -0,0 +1,25 @@
[[!comment format=mdwn
username="joey"
subject="""comment 6"""
date="2021-10-19T16:44:13Z"
content="""
@asakurareiko it makes sense it would fail that way with WAL disabled,
since the sqlite database cannot support multiple writers then. And
there are probably several situations where multiple git-annex processes
end up using the database, even when you are only running a single
git-annex command at a time.
> Without this patch other than adjusted branches, unlocked files generally do
> work in WSL1. Sqlite error may occur at the end of commands such as `git annex get/drop`
Sounds like `restagePointerFile`, which tends to run at the
end of such an operation to handle all the files that have been updated.
That runs `git update-index`, which then runs `git-annex smudge`.
So both the parent and child git-annex process can have the database open
for write, which WAL mode normally supports, but something in WSL prevents
it from working right.
Following this theory, I've made `restagePointerFile` close the database
first. Perhaps that will avoid the problem, at least in those cases. Your
testing is appreciated.
"""]]