Here's yet another weird use case. I have a ext3 external drive for storing media that i brought to the office. Naturally, all files on the drive are owned by my desktop user (uid = 1000). In the office, my userid is different (say 1001), so git-annex doesn't see the removable drive at all (which is a little confusing). But even if i try to add the repo on the drive as an external repo, it says it can't write to it (which is true).
I would expect it to at least be able to leech the files off of it.
Otherwise, I would welcome advice on how to fix this problem without doing a sudo chown -R every time i plug this drive somewhere ... --anarcat
Workaround:
sudo setfacl -R -m u:anarcat:rwx /media/foo/annex
Note: this seems like there was at least one dupe opened about this in ?annex get fails from read-only filesystem.
I concede that this may refer to many different issues, so here's a short inventory of issues with readonly repositories:
- trying to add an external readonly drive through the webapp: not detected: see show readonly removable drives in the webapp
- trying to add an external readonly drive through the commandline: fails to sync? - couldn't reproduce locally, i will need to go back to that machine for more tests
- trying to add a ssh readonly remote through the webapp: fails to sync and considers the remote "git-only" (which also fails) - couldn't reproduce locally either - maybe this is related to the upgrade option in ?annex get fails from read-only filesystem
- trying to add a local readonly remote through the webapp: fails to add, see cannot add local readonly repo through the webapp
- failing to sync with a readonly remote of a different version: still an issue, see ?annex get fails from read-only filesystem - at least content should be syncable even if the upgrade fails (think of failure conditions such as broken hard drives that are put in readonly mode or ddrescue'd disk images)
The assistant ignores drives that it cannot write to. This is a very good heuristic to avoid listing every special device in linux, OSX, etc as possible removable drives. I don't think it makes sense for the assistant to try to handle this use case.
Is there some problem using git-annex at the command line with a remote that is read-only? I don't see any problem in my tests.
so i tried another experiment today: i tried to allow access to a remote user to my /srv/foo annex. the annex is writable by me, but not by the user, yet i was expecting the user to be able to sync with it. not push, mind you, but at least pull: in a "git-only" scenario, that would be perfectly possible. yet the assistant freaks out because it can't run git-annex on the repo because of a write failure on some pack files, and downgrades the repository to a "git-only" repo, which is also inaccurate: it can't sync the metadata either...
i would have expected this repository to be marked as "readonly" and the user be capable of fetching new changes automatically from the "central repo".
maybe that's the essence of the todo here... --anarcat
Note that I still don't have a test case that reproduces this. I have tried and failed a second time to reproduce the original reported problem.
Also, one issue per bug report tends to result in happier developers.
well this specific issue is more about how git-annex cannot get files off readonly medium, whether it is webapp or not.
maybe it would be wiser to split this up in separate bug reports, because I had at least three different situations:
I would need to try the third case through the commandline.
And then there's the upgrade scenario in ?annex get fails from read-only filesystem.
Did i miss anything?
I've made some changes today, which let files be downloaded from readonly repositories (both on local drives and remote, as long as git-annex-shell is updated to a version with the changes).
The issues with the webapp probably remain.