Comments in the moderation queue:
Recent comments posted to this site:
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?
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.
Ok, I found a way to implement it with no added overhead in the common
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:
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.
git annex add
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.)
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.
The assistant will use whatever git remotes and git-annex configuration is
present in the repository when it's started up.
@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
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
The feature is supported in git-annex, but it needs a version of the aws
library that has not seen a stable release yet.
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.