9155ed1072
New command, currently limited to changing autoenable= setting of a special remote. It will probably never be used for more than that given the limitations on it. Sponsored-by: Brock Spratlen on Patreon
65 lines
2.9 KiB
Markdown
65 lines
2.9 KiB
Markdown
### 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.
|
|
|
|
```sh
|
|
# 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.
|
|
|
|
> [[fixed|done]] --[[Joey]]
|
|
|