You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is this issue already tracked somewhere, or is this a new report?
I've reviewed existing issues and couldn't find a duplicate for this problem.
Current Behavior
All objects by s3 earthaccess.download are transferred even if they exist locally.
Expected Behavior
I expected that the s3 earthaccess download would check the object is already available locally (similar to the HTTP) and skip the transfer (e.g., "File MYD04_3K.A2019214.1920.061.2019215152349.hdf already downloaded).
Steps To Reproduce
Compare the earthaccess.download via HTTP versus s3 for a cloud enabled data set.
Environment
- OS:Ubuntu 20.04.6
- Python:3.8.10
Additional Context
No response
The text was updated successfully, but these errors were encountered:
It looks like earthaccess.Store. _download_file implements a simple check for whether the path exists, which is not done in either earthaccess.Store._get_granules or earthaccess.Store._get_urls when using "direct" access logic.
Is this issue already tracked somewhere, or is this a new report?
Current Behavior
All objects by s3 earthaccess.download are transferred even if they exist locally.
Expected Behavior
I expected that the s3 earthaccess download would check the object is already available locally (similar to the HTTP) and skip the transfer (e.g., "File MYD04_3K.A2019214.1920.061.2019215152349.hdf already downloaded).
Steps To Reproduce
Compare the earthaccess.download via HTTP versus s3 for a cloud enabled data set.
Environment
Additional Context
No response
The text was updated successfully, but these errors were encountered: