Recent comments posted to this site:
Just for completeness sake:
K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git-annex version --raw
10.20220927-g26dea5641
K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex drop --force 79698DAC29A079D3-06-06.mrimg
drop 79698DAC29A079D3-06-06.mrimg ok
(recording state in git...)
git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git-annex restage
K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls ..\.git\annex\restage.log
Directory: K:\Reflect-varmistukset\.git\annex
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 1.10.2022 7:47 0 restage.log
K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> time git annex get 79698DAC29A079D3-06-06.mrimg
get 79698DAC29A079D3-06-06.mrimg (from origin...)
ok
(recording state in git...)
git status will show some files to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git-annex restage
00:01:53.0001475
K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> ls ..\.git\annex\restage.log
Directory: K:\Reflect-varmistukset\.git\annex
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 1.10.2022 8:02 0 restage.log
K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git status
On branch adjusted/master(unlocked)
nothing to commit, working tree clean
Found the bug: "fd:16: hFlush: illegal operation (handle is closed)" This exception gets caught after it's actually finished restaging everything, so it displays the warning unncessarily.
Pretty sure the problem on Windows will have the same cause.
Thanks for confirming my feeling that something about the bug as reported was not quite right.
It it was keysdb.cache or keysdb.lck, then it might be a locking problem in git-annex.
But it seems more likely it was keysdb/*.. And that is a sqlite database.
And if sqlite has problems with its internal locking that don't work on
your filesystem, it would be hard to fix that in git-annex. Not using
sqlite or switching the database from WAL mode to non-WAL mode are about
all git-annex could do and both would be major undertakings.
A recently added feature to git-annex is the annex.dbdir git config. That can be set to a directory on another filesystem, and git-annex will store all its sqlite databases in that directory. I think this option is your best chance of avoiding the problem.
Hmm, so it does. This would not have been my choice for ideal behavior, but I don't want to break things that depend on it now. So I've updated the documentation.
Not sure this is quite the same situation, but on linux, I am seeing
git-annex unlock of a locked file display the warning.
Also, .git/annex/restage.log is left empty after the command completes. Which seems to indicate it managed to restage the file after all. Is that file empty for you on windows after it displays the warning and before running other commands?
I noticed that even when the syncing finishes. Worse than that, the 'android/master' branch is merged into 'master'. The removed files are brought back during the merge, but the moved files are committed.
I definitely don't want git annex to touch my master branch. I have 'autocommit = false', 'synconlyannex = true' and 'alwayscommit = false'. I take care of merging and pushing the 'git-annex' branch myself.
Perhaps I'm not using git-annex right ?
So I think I have this issue completely wrong, apologies.
The problem recurred again today, on a v8 repo, and with yesterday's release of git-annex. There is definitely a problem with locking, but it can't be due to the changes in version 10.
To debug further, I removed only some files at a time from the .git/annex directory. The offending files were the keysdb (I did rm -rf keysdb*, so I'm not sure which of the specific files were the offenders).
I'll keep you posted as I debug it further, but I thought I should let you know immediately that my original diagnosis was wrong.
VALUE abc/def/ instead of the VALUE abc/def example mentioned. git-annex-remote-rclone actually assumes the response ends with a slash. Is this indeed what git-annex guarantees? If so, it should probably be documented in this specification.
Yes, thank you, Joey! The annoying (but sometimes necessary) reminder is gone now in regular get/drop circumstances: