It seems like Google Cloud Storage allows you to store object labeled dot ('.'), but the Golang SDK can not find an object labeled dot ('.'), even though it exists. When you relabel the dot file by gsutil mv gs://bucket/path/. gs://bucket/path/name, the SDK will find the storage object.
Even though I can't figure out why anyone would like to name a file as dot (except by accidents), it might be a good idea, that the SDK followed the specifications of the API, if the issue is not about more complex Golang internals.
Can you describe a specific command that does not behave as you expect? I don't understand what the word "find" means in your message.
Do you mean that bkt.Object(".").NewReader returns an error?
I believe it was this line:
source := sourceClient.Object("path/.")
sourceClient is a bucket. The code works after I change the object name from "." to something else by using gsutil mv (changing the name at the bucket and in the code). Same file with different name works. What I mean by "find" is that the SDK gives error, when trying to access a file, which has name ".".
It looks like the storage HTTP API has issues with these paths too. Like you, I can create "foo/.", but can't read it, even when I use curl directly. I've asked the storage team internally about it.
If it helps, I believe I can read it using gsutil (not able to verify atm).
Yes, gsutil cat works for me too.
Heard back from the team. This is an interaction with RFC 3986, which specifies that . and .. are interpreted in URLs as in Unix paths. The Google web frontend implements these rules, meaning the storage service never even sees foo/., just foo. Since the Go client is web-based, it inherits the problem.
We recommend you don't use such paths.
For future reference: internal Google bug 25665561.
Most helpful comment
Heard back from the team. This is an interaction with RFC 3986, which specifies that
.and..are interpreted in URLs as in Unix paths. The Google web frontend implements these rules, meaning the storage service never even seesfoo/., justfoo. Since the Go client is web-based, it inherits the problem.We recommend you don't use such paths.
For future reference: internal Google bug 25665561.