Recent comments posted to this site:

Thanks!

For the record, this is what git will say after git checkout "adjusted/master(unlockpresent)"

Warning: you are leaving 1 commit behind, not connected to
any of your branches:

  9d92415fb git-annex adjusted branch

If you want to keep it by creating a new branch, this may be a good time
to do so with:

 git branch <new-branch-name> 9d92415fb

Switched to branch 'adjusted/master(unlockpresent)'
Comment by gioele Fri Mar 31 20:16:04 2023

Implemented support for https://github.com/yesodweb/persistent/issues/1457 in git-annex, which does speed up sqlite inserts 2x. That will affect the scan in question, since that inserts to the keys database. It also will speed up some unrelated parts of git-annex.

Comment by joey Fri Mar 31 18:36:56 2023
Thanks for doing that. I cannot comment on the unix-compat change, because I'm not familiar with it. But let me use the fix you've just committed and keep an eye on the updates, if any.
Comment by zhongruoyu Fri Mar 31 18:32:29 2023

What if I made git-annex send "EXTENSIONS PROTOCOLVERSION2"? Then you could reply to EXPORTSUPPORTED with EXPORTSUPPORTED-FAILURE when used by a buggy git-annex.

Comment by joey Fri Mar 31 16:55:49 2023

Unfortunately pinning to 0.6 is the only solution, I cannot work around this ill-considered change in git-annex. I have opened an issue and hope the maintainers reconsider. https://github.com/haskell-pkg-janitors/unix-compat/issues/3

Comment by joey Fri Mar 31 16:50:28 2023
Oh, also many thanks for quickly fixing this!
Comment by wolf480 Thu Mar 30 17:33:58 2023

Hmm but a remote only learns that it's being used with exporttree=yes after it has sent a VERSION?

I'm afraid I can't bump the version in case of git-annex-remote-rclone, it's already widely used for non-exporttree scenarios and requiring a git-annex that supports VERSION 2 for these existing usecases (which aren't affected by this bug) would be a regression...

I'll ask git-annex-remote-rclone maintainers, but it seems to me that defensive coding around the EXPORT command is gonna be a better solution in this remote's case.

Comment by wolf480 Thu Mar 30 17:33:10 2023
Thanks for tracking this down, and for the pointer to the annex.crippledfilesystem option. I agree the latter sounds sub-optimal but I'll keep it in mind if staying on the 1.8 release becomes untenable before the Gocryptfs bug is fixed. I'll follow the linked Github issue for updates on that.
Comment by dpifke Wed Mar 29 03:13:50 2023

I've implemented support for VERSION 2. Recommend any external special remotes that support exporttree=yes use it to avoid talking with a buggy git-annex version.

(See better message for external special remote protocol mismatch for related todo.)

Comment by joey Tue Mar 28 20:51:40 2023

What about simply increasing the protocol version number? If VERSION 2 is the same as VERSION 1, but only supported by the fixed git-annex, then an external can just be updated to send VERSION 2, and it does not need to worry about talking with a buggy version of git-annex.

git-annex could either continue to also support VERSION 1, or it could refuse to work with externals that don't use VERSION 2. The latter would force externals to get updated. But then those externals would have no way to work with old git-annex even if they wanted to. I think forcing an update is not called for. So git-annex will keep supporting both versions.

Comment by joey Tue Mar 28 19:29:01 2023