Recent comments posted to this site:

You are right about https access, server does not support git-annex so it is set to meta data only. when using ssh changes are sync (git changes only) but with https changes are not synced (meta data). It is not even listed in repos. When using ssh it is listed in repos as meta data only. I do not store files in the repo just meta data.
Comment by Hamza Tue Oct 13 16:57:24 2015

A and B have different UUIDs, and they point to the same S3 bucket (I realize I may have done something bad here).

I still have the UUID for B (but not attached to a remote); is it possible to merge git annex's knowledge of B into A, or otherwise re-initialize B?

Comment by darkfeline Tue Oct 13 05:24:25 2015

You seem to be talking about using https to access a git repository.

git-annex is not generally able to use https as a transport -- ie, it can maybe download files from a git repository over https, if the repository is set up just right. But it can't upload file to that repository, nor can it promptly notice when changes are synced to that repository from elsewhere.

So, there's not much that the assistant can do with such a repository.

You'll be better off using ssh for your git-annex repositories.

Comment by joey Mon Oct 12 18:52:42 2015
I am not fluent in the webapp. Usually I use the commandline and follow the walktrough on the homepage. Your problem in not being able to see the files is that the NAS has a bare repo. You want a non bare.
Comment by Carl Mon Oct 12 18:21:21 2015

Ok, I found a way to implement it with no added overhead in the common case!

Comment by joey Mon Oct 12 17:37:59 2015

I want to think a little bit about why the location log is updated in this case before thinking about adding an option. It might make sense to just not update the location log when it already says the file is present and only the timestamp is being changed.

I can think of 2 reasons not to do it:

  1. If it has to query the current state of the log, that might slow down git annex add in the common case, just for this less common case.

    But, updating the log necessarily involves reading it in and outputting an updated one, so that could probably be finessed.

    (Or, git annex add makes a separate pass to add unlocked files anyway, so it could only do the query in that case.)

  2. There might be good reasons to want to update the timestamp in the log, since it's just verified that the content is still present. Maybe.

    But then, fsck doesn't update the timestamps when it does the same kind of verification. And, the only thing that updates a given repo's entry in the log is that repo, or another repo that is sending or dropping content from that repo.

    There don't seem to be any reasons of distributed consistency to need to worry about updating the timestamp just to reflect current facts.

Comment by joey Mon Oct 12 17:17:12 2015

The assistant will use whatever git remotes and git-annex configuration is present in the repository when it's started up.

Comment by joey Mon Oct 12 17:15:30 2015

@darkfeline I suppose you're talking about two completely disjoint git repositories, and not two clones of the same parent repo.

If you don't use fileprefix, and have the same file in two disjoint repositories, git-annex will pick the same key for it in both cases, and so you'll get deduplication, but only if you don't use different fileprefixes.

And this will mostly work pretty well. The danger is, if you drop the file from the S3 repo, because say, it's not used anymore in one repository, then you're also removing it from the S3 repo as used by the other repository. If that was the last copy of the file, that may not be what you want.

Comment by joey Mon Oct 12 17:10:21 2015

The feature is supported in git-annex, but it needs a version of the aws library that has not seen a stable release yet.

Comment by joey Mon Oct 12 17:08:06 2015

Seems your guess is right:

joey@darkstar:~/tmp/b4/b>sudo chown root.root -R .git/annex/fsck/4625a6de-d8f5-4036-83a5-6e202ad346da/
joey@darkstar:~/tmp/b4/b>git annex fsck --incremental-schedule 182d

sqlite worker thread crashed: SQLite3 returned ErrorCan'tOpen while attempting to perform prepare "SELECT null from fscked limit 1": unable to open database file
git-annex: thread blocked indefinitely in an MVar operation

So, fix the owner/permissions (or delete .git/annex/fsck) and you should be good to go.

Cleaned up the error message about the MVar, which is something of a red herring.

BTW, I double-checked, and core.sharedRepository is honored to set the mode of the fsck database file, so can be used to share a repo amoung multiple users.

Comment by joey Mon Oct 12 16:49:11 2015