Hello,
I am playing around with different storage options for annexes. I am currently trying the WebDAV solution (with a Sciebo cloud). I created the new sibling successfully with the datalad create-sibling-webdav command, and removed it to try other modes for it.
After a datalad siblings remove -s uni-duesseldorf.sciebo.de-storage and a datalad siblings remove -s uni-duesseldorf.sciebo.de, all traces of the sibling seem to have disappeared from the configuration files.
However, when I try to recreate a sibling for the same WebDAV (with a datalad create-sibling-webdav), I get the following:
create_sibling_webdav(error): . (sibling) [a sibling 'uni-duesseldorf.sciebo.de-storage' is already configured in dataset '/home/simon/Software/DLM']
Can it be that I missed a configuration file? Or is this information cached somewhere?
I would really appreciate any help about this 
Best,
Simon
Hi Simon
The datalad siblings remove command affects only your local git configuration. The *-storage sibling is a git-annex special remote, and indeed there is more information than covered by git config alone. In short, git-annex doesn’t forget things easily by design (e.g. so it can tell where your files used to be, or in case you find the usb drive you thought you lost). To fully answer your question, we’ll need to use some lower-level commands.
After running datalad siblings remove, you can verify that git-annex still retains the information about the special remote by running git annex info (doc), or by peeking directly into one of the files on the git-annex branch with git cat-file blob git-annex:remote.log (if you’re interested in the technical details, git-annex internals page explains its files). Moreover, you should still be able to use git annex enableremote <name> (doc) to recreate related entry in .git/config and make the remote usable again (at least if you didn’t remove it from sciebo in the meantime).
To deal with removing / recreating the sibling, you can do several things:
- use
create-sibling-webdav --existing reconfigure : this will get around the error, but keep in mind the recreated sibling will still have the same annex UUID (so retain its “identity” for git-annex); this is a good solution if you didn’t push data yet, or moved the sciebo folder (so its URL changed but the data stayed the same)
- if you got rid of the sciebo folder containing the storage sibling data, you can use
git annex dead <name> (doc) to tell git-annex that the location is no longer accessible (it will remain recorded but git-annex won’t attempt to use it); you may also need to use git annex renameremote (doc) if you are about to re-use the name, but I’m not sure if that’s necessary
- alternatively, use
git annex forget (doc) to tell git-annex to rewrite its history effectively forgetting the storage sibling existed (“invasive” and potentially destructive)
- in either case, you can use
-s / --name argument for create-sibling-webdav to explicitly select the sibling name instead of relying on the defaults.
Hope that helps!
HI Michał,
Thanks a lot for your answer, this is indeed extremely helpful!
Marking the location dead and renaming it did what I needed. I am still a bit confused about where git annex stores this information, but this will for sure become clearer after some more experiments, and with the nice hints you provided.
Have a nice day,
Best,
Simon