Builds fail if root project is in root of mount point, with further implications

[davidburstromspotify]

Building any project in a root mount point (e.g. C:/ for Windows or / for *nix) fails unless settings.gradle has a rootProject.name= value specified.

Expected Behavior

Gradle should not be smart about the project name, by deducing it from the directory name, but it should be specified explicitly. Especially, this is problematic in a multi-developer environment where the project name can vary greatly depending on what developers are naming their clone directories, and it will affect what's getting reported to Gradle Enterprise, thereby polluting data.

I suppose it could be discouraged as a deprecation, then to be disallowed in a future major release.

Current Behavior

A problem occurred configuring root project ''.
> The project name must not be empty. Set the 'rootProject.name' or adjust the 'include' statement (see https://docs.gradle.org/6.7.1/dsl/org.gradle.api.initialization.Settings.html#org.gradle.api.initialization.Settings:include(java.lang.String[]) for more details).

Context

This was causing issues when I mounted a shared folder in a Windows VirtualBox environment.

Steps to Reproduce

$ gradle -p / --project-cache-dir=$HOME

Your Environment

OS: Windows/macOS
Gradle: 6.8-rc-4

[tresat]

Verified this happens as described.

[donat]

We do recommend Gradle users to specify the root project name in the settings script, so it might make sense to make it required. At the same time, I think there would be a lot of users who would come to this issue and argue that they actually prefer simplicity.

We could also tackle this issue by setting a conventional name (root maybe?) for the root project when the calculated value is an empty string.