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

oops, I misread, still happens for adjusted branches

Browse source
This commit is contained in:
Joey Hess 2021-10-20 13:45:56 -04:00
parent 3f3a2d290f
commit 2801528eb2
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 8 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
CHANGELOG
View file

@ -17,8 +17,7 @@ git-annex (8.20211012) UNRELEASED; urgency=medium
* git-annex get when run as the first git-annex command in a new repo
did not populate all unlocked files.
(Reversion in version 8.20210621)
* Avoid a sqlite crash on Windows SubSystem for Linux (WSL)
when entering an adjusted branch.
* Avoid a some sqlite crashes on Windows SubSystem for Linux (WSL).
-- Joey Hess <id@joeyh.name> Mon, 11 Oct 2021 14:09:13 -0400

10
doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_8_cb7ce88ae3d77b9ba0a4e33c2321a3e1._comment
View file

@ -3,14 +3,14 @@
subject="""comment 7"""
date="2021-10-20T17:04:09Z"
content="""
@asakurareiko oh excellent news!
@asakurareiko oh that's encouraging that I seem to be on the right track.
Before I saw that it's apparently fixed, I noticed that
Adjusted branches still have the same error?
I noticed that
git-annex opened a second connection to the database for writes, in
addition to the connection it used for reads. That seems likely to be
involved in whatever locking problem there is on WSL. While maybe I already
fixed the main one, the fact that fix works makes me even more suspicious
about situations where there are multiple database connections.
involved in whatever locking problem there is on WSL.
Commit [[!commit d0ef8303cf8c4f40a1d17bd134af961fd9917ca4]] eliminates that
second connection. But there's some chance I'll have to revert it.

4
doc/bugs/WSL_adjusted_braches__58___smudge_fails_with_sqlite_thread_crashed_-_locking_protocol/comment_9_b0700fdf101f6cc883857b293cd35267._comment
View file

@ -17,7 +17,7 @@ which would not be helpful. So perhaps it would be better to handle it
like Sqlite.ErrorIO is handled, waiting for up to 1/10th of a second.
But perhaps that would not be enough of a wait.
Anyway, this is a note to myself: If concurrent git-annex processes on Windows
still have this problem, try catching Sqlite.ErrorProtocol and experiment
Anyway, this is a note to myself: If all else fails,
try catching Sqlite.ErrorProtocol and experiment
with different ways to handle it.
"""]]