Recent comments posted to this site:

Ok I'll just wait for the next version. Btw I'm using the latest version: 6.20180112. Thanks!

Comment by ericm Sat Feb 24 03:29:21 2018

There are situations where a git command that appears to be read-only, such as git status actually writes to the repository behind the scenes. It looks like git ignores write errors in at least some such cases. So there is precident for implicit read-only support, but I think not in cases where it would involve significant behavior changes, like it would for the git-annex branch auto-merging. In git's case the behavior change probably only involves repeated git status runs being slower than otherwise, or something like that.

As well as populating the .git/annex/index file with information merged in from recently fetched git-annex branches, git-annex may need to write to other files in order to prepare caches needed to perform what appears to be "read-only" query operation, or to lock files in order to prevent someone who does have write access from dropping them in a situation where that will lose data. An example of the latter is running git annex drop in a repository you do have write access to, and it needing to exclusively lock files in origin, which requires write access to origin as well. Without write access, the drop may fail.

The --read-only flag seems to be setting up a situation where git-annex handles some things being read-only, but then someone expects the flag to make some other thing work read-only, which git-annex can't manage to support for whatever reason.

So I prefer a more specific name, like annex.merge-annex-branches=false.

Implemented that.

Comment by joey Thu Feb 22 17:27:06 2018
I hear you... so far though I was confused by the fact that what I thought would be a read-only operation was actually changing the state of the things (doing the annex merge). Although I would have preferred just a warning like "Cannot merge git-annex branch because of lacking permissions to do so, some information might be not up-to-date", I wondered if then may be a generic resolution could be to add --read-only flag to such commands as info and whereis. Then we (datalad) would be the one to explicitly check if there is write-permissions and if not -- issue the command in --read-only mode. We might even make it a default mode of operation for some of our usecases where it would be confusing if things were changing in the background (e.g. with ls command)
Comment by yarikoptic Thu Feb 22 17:18:18 2018

@arseny-n the misctemp directory does not normally contain anything, or only temp files in use by the currently running git-annex process for a short amount of time. The only way I know of that it can get files piled up in it is when you kill the git-annex process while it's using such a file.

It's always safe to delete the files in misctemp as long as git-annex is not running. Also, the names of the files should give a pretty good clue about what git-annex was using the file for. For example "jlog" files are used for staging the journal.

Comment by joey Thu Feb 22 16:56:13 2018

It seems likely that you have not upgraded git-annex to a version where fsck checks the required content yet, especially since that change has not yet made it into a release of git-annex. It will be in the next release, or you can download a daily build to get it now.

Comment by joey Thu Feb 22 16:51:34 2018

It's true that importfeed calls to download the feed file, without bothering to support annex.web-download-command. That could easily be changed.

However, it also uses Url.getUrlInfo, which does not and cannot use the annex.web-download-command interface, and which is too complicated an interface to make into a hook.

Indeed, annex.web-download-command was never intended to cover all the ways git-annex uses http, but only uses of http to download large file contents. And importfeed does use it for such downloads, but not for its other http needs.

To configure use of a proxy, you would probably be best served by using the http_proxy and https_proxy environment variables, which are supported by wget, curl, and by the haskell http library that git-annex also uses.

Comment by joey Thu Feb 22 16:32:33 2018

The mergedrefs directory is used while building the commit to merge git-annex branches. So even if it was written someplace else, that commit would fail.

I think this may be happening even when there are no git-annex refs to merge in, due to the transition code in Annex.Branch.updateTo that temporarily calls addMergedRefs in the "null tomerge" case. That was added in 2016, and is flagged as able to be safely removed. I've removed it.

However, when there actually is a git-annex branch to merge, if a hypothetical readonly mode avoided doing so, it would necessarily see a different state of the git-annex branch than would be seen in non-readonly mode. That behavior difference could be fairly confusing potentially..

Comment by joey Thu Feb 22 16:17:35 2018

Switching to amazonka would have the benefit of supporting SSL traffic for S3, which is a feature I would enjoy (see git-annex forum thread No SSL traffic for S3?). I have no experience with the amazonka library though, so I can't comment on it.


Comment by andrew Wed Feb 21 18:15:05 2018

Testing, both of the cases in my previous message were actually already working as desired. I think it's done!

Comment by joey Tue Feb 20 17:00:12 2018
I have it working smoothly now with glacier-cli.
Comment by moaxey Mon Feb 19 20:57:09 2018