2 Answers
This is not my strong suit but maybe you could check this logic inthe doco to confirm or refute it.
If the storage ‘can’ use versioning them it must identify the object by something other than just the name, and this would probably be some sort of serialized value so that it increased with time or a hash of date/time.
So logically even if you are not using versionsing, it would attach the serialized ID to all new objects (a consistent treatment is always the easiest to manage)
Between the buckets, the name may be the same, and the object may have the same content, but it is a different object. So although the name is the same in two buckets, each would have been created at different times and logically would have different serialized ID.
This is based on a lot of assumptions, but you should be able to validate this in the Google documentation.
Rusty
I totally agree with Rusty’s assessment, here. The extra stuff at the end of the filename is effectively that file’s identification. And since the two objects are in different buckets, that makes them fundamentally different–they have different identities even though they have the same contents.
Also, even though you happen to control both of those two buckets, right now, the buckets are completely separate and you could potentially transfer ownership of one of them to someone else. So when you use gsutil to copy a file, Google won’t share its identity between your own two buckets any more than between one of your buckets and one of mine.
I hope this helps!
Mattias