Comments in the moderation queue:
Recent comments posted to this site:
This also happens with a second file in the same repo, although the download seems to complete on this one before the error. The file is about the same size.
get otherfile.tgz.gpg (from s3...)
100% 10.7MB/s 0sgpg: WARNING: encrypted message has been manipulated!
Unable to access these remotes: s3
Try making some of these repositories available:
15ac19e4-223a-4c81-b7f7-797b9b026b86 -- [s3]
(Note that these git remotes have annex-ignore set: origin)
git-annex: get: 1 failed
ok, so it is non-fixable reality due to having separate 'annex COMMAND --batch' processes (instead of a single annex --batch process which could accept/carry different COMMANDs with their parameters... I think we had discussion somewhere before).
Ok -- I will workaround (actually for now I have worked around by collecting all files to be dropped and doing that after annex addurl process finishes, but dropkey --batch sounds better for this usecase)
Thank you for your help. I would still like to ask a few related questions.
I was unaware that RSS feeds provide a form of checksum. Are they stored as the filename? I still find it unlikely that the old file was changed in the few minutes between git-annex importing the feed and me asking for the file. However, maybe the file was changed, the feed was not updated and podcast downloading software are not as strict as git-annex.
How should I proceed in order to update my podcasts. This is something I do not understand and I should play a bit with git-annex to figure out: there are multiple ways to remove files. As I understand it:
I tried to git rm -r the podcast directory, and now I cannot importfeed it again. :-S Hmm... It is nothing important, but could you explain me what is going on, please?
git rm -r
A bug made encrypted special remotes that are configured to use chunks accidentially expose the checksums of content that is uploaded to the remote. Such information is supposed to be hidden from the remote's view by the encryption.
What should the users do to repair this situation? How can the exposed checksums be removed from the remote? Is a git annex sync enough?
git annex sync
Thank you for the timely release!
You can do this, but it involves setting that field's value to something.
git annex metadata -s field?=untagged
This will tag all files that don't have any 'field' values with 'untagged', so when you switch to the view, they will show up under 'untagged' (and you move/commit them to tag them).
Yeah, the assistant has a separate code path that writes those wrappers.
I've made it also honor the GIT_ANNEX_PACKAGE_INSTALL setting.
then I guess it is not fully effective... I have removed the copies I had, and when I started 'git annex webapp' 6.20160425+gitgffe2ea2-1~ndall+1 version recreated them
$> which git-annex
$> git annex version
git-annex version: 6.20160425+gitgffe2ea2-1~ndall+1
$> ls -l .ssh/git-annex-*
-rwx------ 1 yoh yoh 215 Apr 27 13:38 .ssh/git-annex-shell*
-rwx------ 1 yoh yoh 61 Apr 27 13:38 .ssh/git-annex-wrapper*