Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent file system emulation compared to actual GCS #1434

Open
anveshreddy18 opened this issue Dec 19, 2023 · 2 comments
Open

Inconsistent file system emulation compared to actual GCS #1434

anveshreddy18 opened this issue Dec 19, 2023 · 2 comments

Comments

@anveshreddy18
Copy link

anveshreddy18 commented Dec 19, 2023

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 GCS till now as gcs uses 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 alpine base 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
Copy link
Owner

fsouza commented 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
Copy link
Author

If I understand correctly, you need something like a set of objects named "foo", "foo/bar", "foo/baz", etc?

Yes, you are right.

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.

Thanks for acknowledging the issue, understood the limitations, hoping to get it redesigned soon. ✌️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants