mirror of
https://github.com/fsouza/fake-gcs-server.git
synced 2026-04-26 14:15:49 +03:00
[GH-ISSUE #1434] Inconsistent file system emulation compared to actual GCS #198
Labels
No labels
bug
compatibility-issue
docker
documentation
enhancement
help wanted
needs information
pull-request
question
stale
unfortunate
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/fake-gcs-server#198
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 @anveshreddy18 on GitHub (Dec 19, 2023).
Original GitHub issue: https://github.com/fsouza/fake-gcs-server/issues/1434
Our application has a requirement that in the store, there be a folder and a file with the same name, as we use the folder to store chunks of the corresponding composite file with the same name as that of folder. This was happening successfully in actual
GCStill now asgcsuses flat hierarchy and maps object name to its content by using the object prefix as it's name. Refer the G cloud doc explaining this.Recently we decided to use the fake server to avoid costs while testing and I have observed that the mock gcs server uses a tree like hierarchical file system ( I know it's because of the
alpinebase image ) which doesn't permit creating a file and a folder with the same name.Is there any plan of supporting a file and folder with the same name in the future?
@fsouza commented on GitHub (Dec 19, 2023):
If I understand correctly, you need something like a set of objects named "foo", "foo/bar", "foo/baz", etc?
I believe this should be supported by the memory backend, but you're correct, the filesystem backend uses a hierarchical structure that isn't compatible with that. At some point we should redesign the filesystem backend to take into consideration generations and other missing capabilities, but there are no clear plans right now.
@anveshreddy18 commented on GitHub (Dec 19, 2023):
Yes, you are right.
Thanks for acknowledging the issue, understood the limitations, hoping to get it redesigned soon. ✌️