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:
parent
20c375d912
commit
29d687dce9
5 changed files with 41 additions and 8 deletions
|
@ -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]]
|
||||
|
|
|
@ -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.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue