From bef2b3f60719bb4d40abdd94bac4024f8edc036b Mon Sep 17 00:00:00 2001 From: mih Date: Fri, 14 Apr 2023 06:55:18 +0000 Subject: [PATCH] Initial report --- ...ing_remote_auto-enabling_not_possible.mdwn | 63 +++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 doc/bugs/Disabling_remote_auto-enabling_not_possible.mdwn diff --git a/doc/bugs/Disabling_remote_auto-enabling_not_possible.mdwn b/doc/bugs/Disabling_remote_auto-enabling_not_possible.mdwn new file mode 100644 index 0000000000..08b7321c75 --- /dev/null +++ b/doc/bugs/Disabling_remote_auto-enabling_not_possible.mdwn @@ -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. +