forum/Help fixing S3 mistakegit-annexhttp://git-annex.branchable.com/forum/Help_fixing_S3_mistake/git-annexikiwiki2015-10-26T17:33:47Zcomment 1http://git-annex.branchable.com/forum/Help_fixing_S3_mistake/comment_1_dc60d08da4c0b90705b0b88b4c834f05/darkfeline2015-10-13T05:24:25Z2015-10-13T05:24:25Z
<p>A and B have different UUIDs, and they point to the same S3 bucket (I realize I may have done something bad here).</p>
<p>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?</p>
comment 2http://git-annex.branchable.com/forum/Help_fixing_S3_mistake/comment_2_f105714b9bac7f45fdcb9a47e77255ac/joey2015-10-15T18:45:50Z2015-10-15T18:30:27Z
<p>Depends.. If one or both special remotes used encryption then no,
one can't see the encrypted files that were put in the other one.</p>
<p>If neither used encryption, and they're otherwise configured the same,
then you can just use <code>git annex fsck --from A</code>. This will check files
to see if their content is located on remote A, and if so, and git-annex
had thought the file was only located on remote B, it will update the location
tracking log to reflect the reality that the file is present on A.</p>
<p>If either remote used encryption, then A can't see files that were added
to B. So instead, you need this approach , which involves data transfer:</p>
<pre><code>git annex enableremote B
git annex copy --from B
git annex copy --to A
git annex drop --from B
git annex dead B # if it wasn't already dead
git remote remove B
</code></pre>
comment 3http://git-annex.branchable.com/forum/Help_fixing_S3_mistake/comment_3_a00bca3b6b0d7b6c20ca1ca749c93469/darkfeline2015-10-18T20:15:56Z2015-10-18T20:15:56Z
<p>Thanks for the help. I'm currently stuck partway through fixing this.</p>
<ol>
<li>I changed the UUID of the remote "amazon" in .git/config to the UUID of B.</li>
<li>I changed contents of the annex-uuid file in the S3 bucket from the UUID of A to the UUID of B (making sure to not include a newline).</li>
</ol>
<p>After this, I think I can follow your steps to fix the problem. However, Git annex is now reporting the error whenever I try to run a command:</p>
<pre><code>trusted repositories: git-annex: S3 bucket not configured
</code></pre>
<p>My understanding of this message is that Git annex is not seeing the UUID it is expecting in the S3 bucket, and that it will be fixed when some cache expires. Is this correct?</p>
comment 4http://git-annex.branchable.com/forum/Help_fixing_S3_mistake/comment_4_34333d0f3eeaf2929089535632759ba1/darkfeline2015-10-18T23:58:08Z2015-10-18T23:58:08Z
<p>Actually, I suspect that I may have done more damage than I had initially thought.</p>
<p>Is there a way to check whether the repo still has information about a file's whereabouts, especially how it was chunked on an S3 remote? I'm not sure if that information still exists or not. If it doesn't exist anymore, then recovery is likely impossible.</p>
<p>If this information still exists in the repo, I can reconstitute the files by hand (script) if necessary and reinject them. I'm assuming that I can decrypt them using my private key?</p>
comment 5http://git-annex.branchable.com/forum/Help_fixing_S3_mistake/comment_5_7060bcd3424caab3570dcc7cbd3df93e/joey2015-10-26T17:33:47Z2015-10-26T17:31:54Z
<p>Since this information about remotes is stored in your git repository, I
don't see how the repository could lose it. I mean, you might have to look
in the history if you've changed some value, like the chunking setting
from what it's supposed to be, in order to find the historical value, but
like anything checked into a git repository, it's there until you throw the
repository away or git-filter-branch the information out of existence.</p>