Please describe the problem.
I have a repository with a special remote that is autoenable=true. The special remote is (no longer) accessible to everyone. I want to disable autoenable, but this fails, because the special remote is not accessible.
How can autoenable be disabled, once a remote is no longer (or even temporarily) inaccessible to someone?
What steps will reproduce the problem?
Here is a small script that demos this for a type-git special remote. However, the problem has been initially observed with different external special remotes. I only reproduced it with a git-annex built-in to see whether an implementation detail in the external special remote is causing this.
# create an annex-repo (using datalad, but this is the standard init+init dance)
$ datalad create originds
# make a clone with datalad (same as clone+init)
$ datalad clone originds dsclone
# add the autoenabling special remote in the clone
$ git -C dsclone annex initremote myremote type=git "location=$(readlink -f originds)" autoenable=true
# as long as `originds` is accessible everything runs smoothly
$ datalad clone dsclone autoclone1
# make the special remote target inaccessible
$ mv originds originds-moved
# enabling is no longer possible
$ datalad clone dsclone autoclone2
$ git -C autoclone2 annex enableremote myremote
...
Remote myremote cannot currently be accessed.
...
# access by special remote name is no possible
$ git -C dsclone annex enableremote myremote autoenable=false
...
Remote myremote cannot currently be accessed.
...
git-annex: That is a normal git remote; passing these parameters does not make sense: autoenable=false
# determine UUID from
# git -C dsclone annex info | grep myremote
# because `git -C dsclone annex info myremote | grep uuid:` no longer lists it
$ git -C dsclone annex enableremote ba87b7e1-4fec-4826-bd01-302a8e2eda0a autoenable=false
Remote myremote cannot currently be accessed.
...
enableremote ba87b7e1-4fec-4826-bd01-302a8e2eda0a error: remote myremote already exists.
git-annex: git [Param "remote",Param "add",Param "myremote",Param "/tmp/originds"] failed
failed
enableremote: 1 failed
# autoenable is still on
$ git -C dsclone cat-file -p git-annex:remote.log
ba87b7e1-4fec-4826-bd01-302a8e2eda0a autoenable=true location=/tmp/originds name=myremote type=git timestamp=1681453180.645186501s
What version of git-annex are you using? On what operating system?
I am on Debian sid. I tried git-annex versions 10.20221003 and 10.20230126 -- both show the same behavior.
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Loads! This particular issue started to show up in the datalad support channels due to aging infrastructure setups with still popular datasets tracking them using autoenabling special remotes.
git-annex deadwill work.But it does seem to me that there is perhaps room to have a way to clear the autoenable setting without killing the remote entirely, but without needing to be able to enableremote the remote.
And I think, when you say "The special remote is (no longer) accessible to everyone" you mean some people still have access, right? But you're not one of those people and want to disable the autoenable.
If so, I ought to add something like
git-annex configremote foo autoenable=false.Yes, in this particular case the situation is as you describe it. The remote itself is fine for a select few, but I (and others) do not have the necessary means to access it. I want to disable autoenable in my "fork" to streamline usage for myself and people like me.
I think your proposed solution would work well for this scenario. Thanks!
Hmm, you could dead it in your fork. The issue would be, if they ever merge from it, their working repo will get marked as dead.
A
git-annex configremotewould likewise cause them problems if they merged from your fork, if they rely on autoenabling being enabled. That's less likely to be a problem to them I suppose.A sub-bug here is that enableremote of a normal git remote adding autoenable=false always fails with "That is a normal git remote; passing these parameters does not make sense: autoenable=false".
That happens even when the repo is accessible. So there is no way to disable a normal git remote that has been initremoted with autoenable=true.
Update: Fixed that.
I retried your example not using a regular git remote, but a special remote. When the special remote is made inaccessible, it does not fail in the same way. Actually, the clone doesn't fail at all:
Likewise
git-annex initdisplays the message from the special remote as a warning but exits successfully and without autoenabling it.Compare with datalad's behavior when it is a regular git remote. The failure there happens because git-annex auto-enables the remote successfully, and then datalad tries to fetch from it, but the repo is not available.
So other than the special case of a git remote stored by initremote, this bug's real impact seems to only be that enableremote can't be used to change the configuration of a remote that's not accessible and
git-annex initwill warn about such a remote.Seems that
git-annex configremotewould be very limited in what configuration it can change. Changing configuration with enableremote re-runs thesetupmethod, which is passed a RemoteConfig with the user's proposed changes and can either fail if the config is not valid, or return a RemoteConfig that might not be the same as the input one. Sincesetupalso prepares to use the remote, which is what's failing when the remote is not accessible, it could not be used byconfigremote.So, I think autoenable is about the only config setting that it would make sense for configremote to be able to change. Changing anything else would risk storing a configuration that
setupwould not allow. Which could break the remote in arbitrary ways.git-annex configremote