When retrival from a chunked remote fails, display the error that occurred when downloading the chunk

Rather than the error that occurred when trying to download the unchunked
content, which is less likely to actually be stored in the remote.

Sponsored-by: Boyd Stephen Smith Jr. on Patreon
This commit is contained in:
Joey Hess 2021-10-14 12:45:05 -04:00
parent 20c375d912
commit 29d687dce9
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 41 additions and 8 deletions

View file

@ -115,3 +115,5 @@ ongoing-request="false", expiry-date="Mon, 26 Apr 2021 00:00:00 GMT"
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Yes, for loads of stuff. It's awesome, thanks!
> [[closed|done]], see my comment --[[Joey]]

View file

@ -0,0 +1,19 @@
[[!comment format=mdwn
username="joey"
subject="""comment 5"""
date="2021-10-14T16:17:14Z"
content="""
I have added a note to the S3 documentation about `DEEP_ARCHIVE` and the
glacier special remote.
I have made git-annex display the exception for the more likely chunked
location, rather than the less likely unchunked location, when retrieving
from both locations fails. Although it's still possible for there to be
situations where the exception if displays is not for the location where
the content actually is. Eg, if the chunk size of the remote has
changed over time.
I think that todo is basically talking about the same desire to make the S3
remote support these glacier-style storage classes, in one way or another,
and so I think this bug report can be closed as otherwise a duplicate of it.
"""]]