I found this note in the docs

Cloud Storage uses a flat namespace and therefore doesn't support real directories. So this library supports what's known as "pseudo-directories". Any path that includes a trailing slash, will be considered a directory. It will always be assumed to exist, without performing any I/O. This allows you to do path manipulation in the same manner as you would with the normal UNIX file system implementation. You can disable this feature with [CloudStorageConfiguration.usePseudoDirectories()](https://www.mvndoc.com/c/com.google.cloud/gcloud-java-nio/com/google/cloud/storage/contrib/nio/CloudStorageConfiguration.html#usePseudoDirectories()).

https://www.mvndoc.com/c/com.google.cloud/gcloud-java-nio/index.html

This seems to be the reasoning behind why
Files.exists(Paths.get(new URI("gs://bucketthatdoesntexist/thing/"))); returns true.

@sydney-munro Ah, thanks for diving for that! From that description it's not clear though that just "gs://bucketthatdoesntexist should also return true. And it's definitely not the case that it should crash.

It sounds like it would be a change of behavior, but I would expect Files.exist() to return false on any file in a bucket that doesn't exist, (or the bucket itself), even if it ends in a /. I guess the analogy I have in my head is asking the local file system if a file exists on a drive that isn't there.

I agree, it has to do with when we probe to actually see if we can perform I/O, but yes ultimately we should be returning some sort of error such as a FileSystemNotFoundException.

Give me until tomorrow to sort out a path forward for handling this more appropriately.

Thank you for looking into it! I think we would definitely appreciate it returning false instead of an exception in the case the bucket doesn't exist. I don't think the file not existing should be an exceptional case when checking if the file exists.

Other cases like "can't determine if the file exists because you lack permissions" are obviously a different case.

Thats understandable. Our concern is deviating from what would be standard behavior. For example if a file does not exist
a standard thought would be that they are able to create this file, which is not true if the bucket does not exist.

Whereas we believe FileSystemNotFoundException is more appropriate.
See documentation for Paths.get

Apologies on the delay of getting back to this. So I have gone through the code and thought about the options.
What I have come up with so far is:
These return FileSystemNotFoundException:

• Files.exists(Paths.get(new URI("gs://bucketthatdoesntexist/thing")));
• Files.exists(Paths.get(new URI("gs://bucketthatdoesntexist)));

This returns true:

• Files.exists(Paths.get(new URI("gs://bucketthatdoesntexist/thing/")));

This is mainly to stay consistent with my initial comment however i do find that confusing. I would much prefer to return FileSystemNotFoundException for all of these cases

lbergelson apologies on the back and forth here. I spoke with the team and you also mentioned some similar concerns on my approach of using CloudStorageFileSystemProvider.getPath to check the existence of a bucket regarding lifecycle and the possibility of changing state while the program runs placing us in the same position as before with an unintended storage exception.

Given this we will not be reworking the behavior and rather manage wrapping the storage exception in something more appropriate.

We will continue to have these return true, and update the documentation to be more clear.

Files.exists(Paths.get(new URI("gs://bucketthatdoesntexist/thing/")));
Files.exists(Paths.get(new URI("gs://bucketthatdoesntexist)));

This case will be handled to throw an appropriate error.

Files.exists(Paths.get(new URI("gs://bucketthatdoesntexist/thing")));