mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

Initial report

Browse source
This commit is contained in:
mih 2023-04-14 06:55:18 +00:00 committed by admin
parent 2efceba789
commit bef2b3f607
1 changed files with 63 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

63
doc/bugs/Disabling_remote_auto-enabling_not_possible.mdwn Normal file
View file

@ -0,0 +1,63 @@
### 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.