Recent comments posted to this site:

Yes, thank you, Joey! The annoying (but sometimes necessary) reminder is gone now in regular get/drop circumstances:

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...)
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    11:08              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
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...)
00:01:50.7710391
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    11:11              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
K:\Reflect-varmistukset\Jarkon ThinkPad T450s (Win10 v21H1) . B [adjusted/master(unlocked)]> git annex version --raw
10.20220928-g49ee07f93

:)

Comment by jkniiv Sat Oct 1 08:23:43 2022

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
Comment by jkniiv Sat Oct 1 05:14:17 2022
I've fixed this, and I'm planning to make a minor release on Monday for it.
Comment by joey Fri Sep 30 17:55:20 2022

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.

Comment by joey Fri Sep 30 17:43:13 2022

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.

Comment by joey Fri Sep 30 17:34:34 2022

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.

Comment by joey Fri Sep 30 17:31:25 2022

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?

Comment by joey Fri Sep 30 17:24:27 2022

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 ?

Comment by jules Thu Sep 29 09:26:05 2022

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.

Comment by kdm9 Wed Sep 28 12:55:49 2022
DIRHASH-LOWER (and I assume the other DIRHASH commands as well) seem to respond with a path ending with a slash. So 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.
Comment by jeroen Wed Sep 28 11:58:56 2022