This looks like it would be a relatively simple feature to add, eg an hour or two, and I see in the forum that @yarik thinks ReproNim can use it. So I'll go ahead...

Well spotted. git-annex add defaults to adding files locked, even when adding what was an unlocked file before.

I've improved the example.

SETCONFIG is limited to setting the external program's configuration, not to reaching inside git-annex and setting its own configuration. The docs say that, but could perhaps be more clear.

I have improved the error message.

git-annex sets up encryption for the remote based on the encryption= and encryptonlycreds= settings before it ever starts up the external program. That would need to change in order to support this.

But I'm also doubtful it would be a good idea to support SETCONFIG of any of the things git-annex uses for encryption, chunking, etc. It's essentially monkey-patching git-annex from the external program. Some changes to git-annex's configs could lead to very unexpected behavior.

If you really need the ability to turn on onlyencryptcreds by default with your special remote, there will need to be some other way implemented to do it. Please open a new todo about that.

There was another bug filed about the same problem, ?strong>unlock fails for some names.

Cause is a filename that is 21 bytes long and begins with a utf-8 character. Which AFAICS all the filenames mentioned here are.

67f00027d1b326c979db8b81c973a61234c406d7 fixes this.

Yay!

OsPath needs the os-string and file-io haskell packages. Which are not currently in Debian. So either work will need to be done to package those, or when Debian upgrades ghc to 9.12.2, it will include those libraries automatically since they are bundled with ghc since that version.

Maybe you know more than I do about the state of Debian's haskell support.

The transition is being tracked at RawFilePath conversion but I don't know yet what the solution is to getting the dependencies broadly available.

(Or I could implement the same fixes when not built with that flag of course. It is doable. Just annoying especially since that code will have to be carefully gotten just right, only to be thrown away later.)

that version had no errors: All tests succeeded. (Ran 50 test groups in 11m54s)

So, this will be default option? any specific dependency requirements we need to add/constrain?

I have enabled OsPath in the build at https://downloads.kitenet.net/git-annex/autobuild/amd64/git-annex-standalone-amd64.tar.gz

Confirmed in your log that git-annex is not built with the OsPath build flag, so it will still not be using O_CLOEXEC.

It would be good to get a build with OsPath and test it to see if my fixes actually did work. Debian doesn't include the necessary library yet, so a build using stack is needed.