mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 13:26:00 +03:00
[GH-ISSUE #1662] Look at GCS-specific headers #870
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#870
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @gaul on GitHub (May 20, 2021).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1662
s3fs should have a GCS mode which uses headers like
x-goog-storage-classinstead ofx-amz-storage-class:https://cloud.google.com/storage/docs/xml-api/reference-headers#xgoogstorageclass
Related to #1613.
@ggtakec commented on GitHub (May 20, 2021):
@gaul Should we switch to use
x-goog-meta-*andx-amz-meta*properly?@gaul commented on GitHub (May 20, 2021):
I think we might want to add a
--gcsflag or automatically change to GCS mode based on--urlmatching storage.googleapis.com.@ggtakec commented on GitHub (May 20, 2021):
Both look good. However, considering that there may be such differences in other parts in the future, I think the
--gcsoption seems to be better.@gaul commented on GitHub (May 22, 2021):
This bug may be invalid. GCS supports
x-amz-storage-classand it doesn't appear that the other headers provide any value, except for conditional PUT. I think there are some other ETag sanity checks that we should do before looking at vendor-specific conditional PUT though.