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.

Sign up for GitHub

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

Jump to bottom

Windows, macOS: package names and input-file-target names are case-ignoring #8799

Closed
laszlocsomor opened this issue Jul 5, 2019 · 2 comments
Closed

Windows, macOS: package names and input-file-target names are case-ignoring #8799

laszlocsomor opened this issue Jul 5, 2019 · 2 comments
Labels
area-Windows Windows-specific issues and feature requests P2 We'll consider working on this in future. (Assignee optional) stale Issues or PRs that are stale (no activity for 30 days) team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website type: bug

Comments

@laszlocsomor
Copy link
Contributor

laszlocsomor commented Jul 5, 2019 •
edited
Loading

Description of the problem / feature request:

Bazel does not enforce correct casing in package names, nor in target names (if they refer to input files).

Bazel only enforces correct casing in target names that are rules or output files. (Because these are defined as strings in the BUILD file.)

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Repro on Windows -- in cmd.exe:

md c:\src\tmp\case\Foo\Bar

cd c:\src\tmp\case

type nul > WORKSPACE

echo Servus > Foo\Bar\Hello

echo genrule(name="x",srcs=["foo/bar/hello"],outs=["x.out"],cmd="(echo $< ; cat $< ;) > $@") > BUILD

bazel build //:x & type bazel-bin\x.out
(...)
INFO: Build completed successfully, 2 total actions
foo/bar/hello
Servus

Repro on macOS -- in Bash:

mkdir -p /tmp/case/Foo/Bar

cd /tmp/case

touch WORKSPACE

echo Servus > Foo/Bar/Hello

echo 'genrule(name="x",srcs=["foo/bar/hello"],outs=["x.out"],cmd="(echo $< ; cat $< ;) > $@")' > BUILD

bazel build //:x && cat bazel-bin/x.out
(...)
INFO: Build completed successfully, 2 total actions
foo/bar/hello
Servus

What operating system are you running Bazel on?

Windows 10
macOS 10.15.1

What's the output of bazel info release?

release 1.2.1

Have you found anything relevant by searching the web?

Same culprit as #7627.
@laszlocsomor laszlocsomor changed the title Windows: Windows: package names and input-file-target names are case-ignoring Jul 5, 2019
@laszlocsomor laszlocsomor self-assigned this Jul 5, 2019
@laszlocsomor laszlocsomor added bazel 1.0 P2 We'll consider working on this in future. (Assignee optional) area-Windows Windows-specific issues and feature requests type: bug labels Jul 5, 2019
@laszlocsomor laszlocsomor mentioned this issue Jul 5, 2019
Closed
@dslomov dslomov removed the bazel 1.0 label Jul 24, 2019
This was referenced Sep 24, 2019
Closed
Closed
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Sep 25, 2019
@laszlocsomor
Windows: implement getCorrectCasing
4a83aee 
Implement getCorrectCasing: a function that
normalizes a path and returns the case-correct
version of it.

See bazelbuild#8799
@laszlocsomor laszlocsomor mentioned this issue Sep 25, 2019
Closed
bazel-io pushed a commit that referenced this issue Sep 25, 2019
@laszlocsomor @copybara-github
Windows: implement getCorrectCasing
06d2f6d 
Implement getCorrectCasing: a function that
normalizes a path and returns the case-correct
version of it.

See #8799

Closes #9435.

PiperOrigin-RevId: 271083623
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Oct 4, 2019
@laszlocsomor
Support case-sensitive package loading
2d4bf4c 
The --incompatible_validate_package_path_casing
flag enables a new validation step in package
loading: when enabled, Bazel requires that package
paths be case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I9d55cd76b2499172cb55252032163d936b83690e
@laszlocsomor laszlocsomor mentioned this issue Oct 4, 2019
Closed
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Oct 17, 2019
@laszlocsomor
Support case-sensitive package loading
ce56ef9 
The --incompatible_validate_package_path_casing
flag enables a new validation step in package
loading: when enabled, Bazel requires that package
paths be case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I9d55cd76b2499172cb55252032163d936b83690e
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Oct 17, 2019
@laszlocsomor
Support case-sensitive package loading
18695b5 
The --incompatible_validate_package_path_casing
flag enables a new validation step in package
loading: when enabled, Bazel requires that package
paths be case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I9d55cd76b2499172cb55252032163d936b83690e
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Oct 31, 2019
@laszlocsomor
Support case-sensitive package loading
d6116e5 
The --incompatible_validate_package_path_casing
flag enables a new validation step in package
loading: when enabled, Bazel requires that package
paths be case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I9d55cd76b2499172cb55252032163d936b83690e
bazel-io pushed a commit that referenced this issue Oct 31, 2019
@laszlocsomor @copybara-github
Automated rollback of commit 06d2f6d.
6e167e6 
*** Reason for rollback ***

We must implement path case fixing on top of Skyframe (by requesting DirectoryListingValue), rather than as a JNI method. That way clients get invalidated when a path is renamed such that only the casing changes.

*** Original change description ***

Windows: implement getCorrectCasing

Implement getCorrectCasing: a function that
normalizes a path and returns the case-correct
version of it.

See #8799

Closes #9435.

PiperOrigin-RevId: 277688249
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Nov 6, 2019
@laszlocsomor
Support case-sensitive package loading
bcebac9 
The --incompatible_validate_package_path_casing
flag enables a new validation step in package
loading: when enabled, Bazel requires that package
paths be case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I9d55cd76b2499172cb55252032163d936b83690e
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Nov 6, 2019
@laszlocsomor
Support case-sensitive package loading
8cc0083 
The --incompatible_validate_package_path_casing
flag enables a new validation step in package
loading: when enabled, Bazel requires that package
paths be case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I9d55cd76b2499172cb55252032163d936b83690e
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Nov 11, 2019
@laszlocsomor
Support case-sensitive package loading
58bd048 
The --incompatible_validate_package_path_casing
flag enables a new validation step in package
loading: when enabled, Bazel requires that package
paths be case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I9d55cd76b2499172cb55252032163d936b83690e
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 2, 2019
@laszlocsomor
Support case-sensitive package loading
c03e7fd 
The new --[no]experimental_check_label_casing flag
enables a new validation step in package loading:
when enabled, Bazel requires that package paths be
case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I5ad86a0ede6f85aa9cac8e8e56072630738db55c
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 2, 2019
@laszlocsomor
Support case-sensitive package loading
6286ec6 
The new --[no]experimental_check_label_casing flag
enables a new validation step in package loading:
when enabled, Bazel requires that package paths be
case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I5ad86a0ede6f85aa9cac8e8e56072630738db55c
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 2, 2019
@laszlocsomor
Support case-sensitive package loading
caa76dc 
The new --[no]experimental_check_label_casing flag
enables a new validation step in package loading:
when enabled, Bazel requires that package paths be
case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I5ad86a0ede6f85aa9cac8e8e56072630738db55c
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 2, 2019
@laszlocsomor
Support case-sensitive package loading
00aea34 
The new --[no]experimental_check_label_casing flag
enables a new validation step in package loading:
when enabled, Bazel requires that package paths be
case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I5ad86a0ede6f85aa9cac8e8e56072630738db55c
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 2, 2019
@laszlocsomor
Support case-sensitive package loading
13aeeee 
The new --[no]experimental_check_label_casing flag
enables a new validation step in package loading:
when enabled, Bazel requires that package paths be
case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I5ad86a0ede6f85aa9cac8e8e56072630738db55c
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 2, 2019
@laszlocsomor
Support case-sensitive package loading
382be37 
The new --[no]experimental_check_label_casing flag
enables a new validation step in package loading:
when enabled, Bazel requires that package paths be
case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I5ad86a0ede6f85aa9cac8e8e56072630738db55c
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 2, 2019
@laszlocsomor
Support case-sensitive package loading
80b9125 
The new --[no]experimental_check_label_casing flag
enables a new validation step in package loading:
when enabled, Bazel requires that package paths be
case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I5ad86a0ede6f85aa9cac8e8e56072630738db55c
@laszlocsomor laszlocsomor changed the title Windows: package names and input-file-target names are case-ignoring Windows, macOS: package names and input-file-target names are case-ignoring Dec 2, 2019
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 2, 2019
@laszlocsomor
Support case-sensitive package loading
564f7ee 
The new --[no]experimental_check_label_casing flag
enables a new validation step in package loading:
when enabled, Bazel requires that package paths be
case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I5ad86a0ede6f85aa9cac8e8e56072630738db55c
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 2, 2019
@laszlocsomor
Support case-sensitive package loading
da07e03 
The new --[no]experimental_check_label_casing flag
enables a new validation step in package loading:
when enabled, Bazel requires that package paths be
case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I5ad86a0ede6f85aa9cac8e8e56072630738db55c
@laszlocsomor laszlocsomor mentioned this issue Dec 2, 2019
Closed
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 2, 2019
@laszlocsomor
Support case-sensitive package loading
88c07a9 
The new --[no]experimental_check_label_casing flag
enables a new validation step in package loading:
when enabled, Bazel requires that package paths be
case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I5ad86a0ede6f85aa9cac8e8e56072630738db55c
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 2, 2019
@laszlocsomor
Support case-sensitive package loading
98afc75 
The new --[no]experimental_check_label_casing flag
enables a new validation step in package loading:
when enabled, Bazel requires that package paths be
case-correct.

When the user runs "bazel build //Foo/Bar:Baz",
Bazel looks up the package "Foo/Bar" by stat'ing
"Foo/Bar/BUILD". If the file exists, then the
package exists. Every Label that Bazel creates in
this package is derived from the "Foo/Bar" string.

On Linux the filesystem is case-sensitive, so the
path casing must be correct for stat() to succeed,
so it's impossible to load the package "//Foo/Bar"
as "//FOO/baR".

On Windows and macOS the filesystem ignores the
difference between lower and upper case letters,
so stat("foo/bAr/BUILD") and stat("FOO/bar/build")
would both suceed, so "bazel build //foo/bAr:Baz"
and "bazel build //FOO/bar:Baz" both work. This
leads to bugs such as bazelbuild#6401, bazelbuild#8009, and bazelbuild#8799.

Change-Id: I5ad86a0ede6f85aa9cac8e8e56072630738db55c
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 3, 2019
@laszlocsomor
VFS: add RootedPathAndCasing
834b677 
This class stores a RootedPath and the String
value of its relative part.

This class allows distinguishing RootedPaths on
case-insensitive filesystems, if the RootedPaths
refer to the same file but use different casing.

The class only compares the casing of the relative
parts, not of the root parts. Reason is, this
class will be used to validate the casing of
package paths, which are always relative to the
package root.

See bazelbuild#8799

Change-Id: Ie742f95a7feb3935c93cbba6db9278b63cfcc63a
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 3, 2019
@laszlocsomor
VFS: add RootedPathAndCasing
65961ef 
This class stores a RootedPath and the String
value of its relative part.

This class allows distinguishing RootedPaths on
case-insensitive filesystems, if the RootedPaths
refer to the same file but use different casing.

The class only compares the casing of the relative
parts, not of the root parts. Reason is, this
class will be used to validate the casing of
package paths, which are always relative to the
package root whose casing we needn't worry about.

See bazelbuild#8799

Change-Id: Ie742f95a7feb3935c93cbba6db9278b63cfcc63a
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 3, 2019
@laszlocsomor
VFS: add RootedPathAndCasing
2ee6bc1 
This class stores a RootedPath and the String
value of its relative part.

This class allows distinguishing RootedPaths on
case-insensitive filesystems, if the RootedPaths
refer to the same file but use different casing.

The class only compares the casing of the relative
parts, not of the root parts. Reason is, this
class will be used to validate the casing of
package paths, which are always relative to the
package root whose casing we needn't worry about.

See bazelbuild#8799

Change-Id: Ie742f95a7feb3935c93cbba6db9278b63cfcc63a
@laszlocsomor laszlocsomor mentioned this issue Dec 3, 2019
Closed
bazel-io pushed a commit that referenced this issue Dec 4, 2019
@laszlocsomor @copybara-github
VFS: add RootedPathAndCasing
be5630b 
This class stores a RootedPath and the String
value of its relative part.

This class allows distinguishing RootedPaths on
case-insensitive filesystems, if two RootedPaths
refer to the same file but use different casing.

The motivation is to support validating package
path casing. (See issue #8799.) My plan is to add
a new SkyFunction called PathCasingLookupFunction,
which validates that a certain RootedPath is
correctly cased. The SkyKey can't just take a
RootedPath, because on Windows the path semantics
dictate that RootedPath objects are compared
without regard to casing. Thus we must also store
the particular casing in the SkyKey, and so we
need the RootedPathWithCasing class.

The class only compares the casing of the relative
parts, not of the root parts. Reason is, this
class will be used to validate the casing of
package paths, which are always relative to the
package root whose casing we needn't worry about.

See #8799

Closes #10357.

Change-Id: Ie742f95a7feb3935c93cbba6db9278b63cfcc63a
PiperOrigin-RevId: 283705461
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 4, 2019
@laszlocsomor
New SkyFunction: PathCasingLookupFunction
3b1df1f 
The new PathCasingLookupFunction is a SkyFunction
that can validate the casing of a path.

On case-insensitive filesystems if "foo/BUILD"
exists then "FOO/BUILD" also exists (because they
mean the same file), but this should not imply
that the "//foo" and "//FOO" packages both exist.

The new SkyFunction can validate whether
"FOO/BUILD" is the correct casing. The casing is
correct if the file's name in its parent
directory's listing is exactly the same
(case-sensitively) as the expected name.

In a later PR we can change the
PackageLookupFunction to deny loading if the path
is not correctly cased.

Change-Id: Ibb2a5f4f6c6041bdfc537b33d0c6fc55e568b998
Motivation: bazelbuild#8799
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 4, 2019
@laszlocsomor
New SkyFunction: PathCasingLookupFunction
7d00418 
The new PathCasingLookupFunction is a SkyFunction
that can validate the casing of a path.

On case-insensitive filesystems if "foo/BUILD"
exists then "FOO/BUILD" also exists (because they
mean the same file), but this should not imply
that the "//foo" and "//FOO" packages both exist.

The new SkyFunction can validate whether
"FOO/BUILD" is the correct casing. The casing is
correct if the file's name in its parent
directory's listing is exactly the same
(case-sensitively) as the expected name.

In a later PR we can change the
PackageLookupFunction to deny loading if the path
is not correctly cased.

Change-Id: Ibb2a5f4f6c6041bdfc537b33d0c6fc55e568b998
Motivation: bazelbuild#8799
@laszlocsomor laszlocsomor mentioned this issue Dec 4, 2019
Closed
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 4, 2019
@laszlocsomor
Add case-checking PackageIdentifier
9a1572a 
If the "bazel.check_label_casing" JVM property is
"1", then PackageIdentifier objects will store not
only the RepositoryName and PathFragment, but also
the toString() values of those.

These augmented PackageIdentifiers (actually:
CaseCheckingPackageIdentifiers) allow telling
apart PackageIdentifiers whose RepositoryName and
PathFragment values are equal but are cased
differently. This scenario is common on
case-insensitive filesystems, where the paths
"foo/x" and "FoO/X" are equal but differently
cased.

Motivation is to allow case-checking the package
names in PackageLookupFunction.

The SkyKey of PackageLookupFunction contains a
PackageIdentifier, which holds a reference to the
RepositoryName and PathFragment (package
fragment). On case-insensitive filesystems, both
of these objects check equality without regard to
case, and so do PackageIdentifiers as a
consequence.

But PackageIdentifier objects are interned for
better memory usage, which means that on a
case-insensitive filesystem it's impossible to
create two PackageIdentifiers whose RepositoryName
and PathFragment are equal but differently cased.
And that means it's also impossible to check in
the PackageLookupFunction whether the requested
package path (and thus the PackageIdentifier) has
correct casing.

With this PR, PackageIdentifier.create() will
return CaseCheckingPackageIdentifier when case
checking is enabled, so PackageLookupFunction will
know exactly what casing the user requested, and
can therefore validate that casing and deny
loading the package if the casing is wrong. And
that is what would fix bazelbuild#8799

Change-Id: I46106f83c0a5b16fa347dd8a07e3c5342248c605
@laszlocsomor laszlocsomor mentioned this issue Dec 4, 2019
Closed
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 5, 2019
@laszlocsomor
New SkyFunction: PathCasingLookupFunction
a14908e 
The new PathCasingLookupFunction is a SkyFunction
that can validate the casing of a path.

On case-insensitive filesystems if "foo/BUILD"
exists then "FOO/BUILD" also exists (because they
mean the same file), but this should not imply
that the "//foo" and "//FOO" packages both exist.

The new SkyFunction can validate whether
"FOO/BUILD" is the correct casing. The casing is
correct if the file's name in its parent
directory's listing is exactly the same
(case-sensitively) as the expected name.

In a later PR we can change the
PackageLookupFunction to deny loading if the path
is not correctly cased.

Change-Id: Ibb2a5f4f6c6041bdfc537b33d0c6fc55e568b998
Motivation: bazelbuild#8799
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 5, 2019
@laszlocsomor
Add case-checking PackageIdentifier
1dedadf 
If the "bazel.check_label_casing" JVM property is
"1", then PackageIdentifier objects will store not
only the RepositoryName and PathFragment, but also
the toString() values of those.

These augmented PackageIdentifiers (actually:
CaseCheckingPackageIdentifiers) allow telling
apart PackageIdentifiers whose RepositoryName and
PathFragment values are equal but are cased
differently. This scenario is common on
case-insensitive filesystems, where the paths
"foo/x" and "FoO/X" are equal but differently
cased.

Motivation is to allow case-checking the package
names in PackageLookupFunction.

The SkyKey of PackageLookupFunction contains a
PackageIdentifier, which holds a reference to the
RepositoryName and PathFragment (package
fragment). On case-insensitive filesystems, both
of these objects check equality without regard to
case, and so do PackageIdentifiers as a
consequence.

But PackageIdentifier objects are interned for
better memory usage, which means that on a
case-insensitive filesystem it's impossible to
create two PackageIdentifiers whose RepositoryName
and PathFragment are equal but differently cased.
And that means it's also impossible to check in
the PackageLookupFunction whether the requested
package path (and thus the PackageIdentifier) has
correct casing.

With this PR, PackageIdentifier.create() will
return CaseCheckingPackageIdentifier when case
checking is enabled, so PackageLookupFunction will
know exactly what casing the user requested, and
can therefore validate that casing and deny
loading the package if the casing is wrong. And
that is what would fix bazelbuild#8799

Change-Id: I46106f83c0a5b16fa347dd8a07e3c5342248c605
bazel-io pushed a commit that referenced this issue Dec 5, 2019
@laszlocsomor @copybara-github
New SkyFunction: PathCasingLookupFunction
7d68029 
The new PathCasingLookupFunction is a SkyFunction
that can validate the casing of a path.

On case-insensitive filesystems if "foo/BUILD"
exists then "FOO/BUILD" also exists (because they
mean the same file), but this should not imply
that the "//foo" and "//FOO" packages both exist.

The new SkyFunction can validate whether
"FOO/BUILD" is the correct casing. The casing is
correct if the file's name in its parent
directory's listing is exactly the same
(case-sensitively) as the expected name.

In a later PR we can change the
PackageLookupFunction to deny loading if the path
is not correctly cased.

Motivation: #8799

Change-Id: Ibb2a5f4f6c6041bdfc537b33d0c6fc55e568b998

Closes #10362.

Change-Id: Ie25b9b202a1aef3b2594064b4842fc0f2fb2776b
PiperOrigin-RevId: 283939452
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 5, 2019
@laszlocsomor
Add case-checking PackageIdentifier
f76615b 
If the "bazel.check_label_casing" JVM property is
"1", then PackageIdentifier objects will store not
only the RepositoryName and PathFragment, but also
the toString() values of those.

These augmented PackageIdentifiers (actually:
CaseCheckingPackageIdentifiers) allow telling
apart PackageIdentifiers whose RepositoryName and
PathFragment values are equal but are cased
differently. This scenario is common on
case-insensitive filesystems, where the paths
"foo/x" and "FoO/X" are equal but differently
cased.

Motivation is to allow case-checking the package
names in PackageLookupFunction.

The SkyKey of PackageLookupFunction contains a
PackageIdentifier, which holds a reference to the
RepositoryName and PathFragment (package
fragment). On case-insensitive filesystems, both
of these objects check equality without regard to
case, and so do PackageIdentifiers as a
consequence.

But PackageIdentifier objects are interned for
better memory usage, which means that on a
case-insensitive filesystem it's impossible to
create two PackageIdentifiers whose RepositoryName
and PathFragment are equal but differently cased.
And that means it's also impossible to check in
the PackageLookupFunction whether the requested
package path (and thus the PackageIdentifier) has
correct casing.

With this PR, PackageIdentifier.create() will
return CaseCheckingPackageIdentifier when case
checking is enabled, so PackageLookupFunction will
know exactly what casing the user requested, and
can therefore validate that casing and deny
loading the package if the casing is wrong. And
that is what would fix bazelbuild#8799

Change-Id: I46106f83c0a5b16fa347dd8a07e3c5342248c605
laszlocsomor added a commit to laszlocsomor/bazel that referenced this issue Dec 5, 2019
@laszlocsomor
Add case-checking PackageIdentifier
87f02e3 
If the "bazel.check_label_casing" JVM property is
"1", then PackageIdentifier objects will store not
only the RepositoryName and PathFragment, but also
the toString() values of those.

These augmented PackageIdentifiers (actually:
CaseCheckingPackageIdentifiers) allow telling
apart PackageIdentifiers whose RepositoryName and
PathFragment values are equal but are cased
differently. This scenario is common on
case-insensitive filesystems, where the paths
"foo/x" and "FoO/X" are equal but differently
cased.

Motivation is to allow case-checking the package
names in PackageLookupFunction.

The SkyKey of PackageLookupFunction contains a
PackageIdentifier, which holds a reference to the
RepositoryName and PathFragment (package
fragment). On case-insensitive filesystems, both
of these objects check equality without regard to
case, and so do PackageIdentifiers as a
consequence.

But PackageIdentifier objects are interned for
better memory usage, which means that on a
case-insensitive filesystem it's impossible to
create two PackageIdentifiers whose RepositoryName
and PathFragment are equal but differently cased.
And that means it's also impossible to check in
the PackageLookupFunction whether the requested
package path (and thus the PackageIdentifier) has
correct casing.

With this PR, PackageIdentifier.create() will
return CaseCheckingPackageIdentifier when case
checking is enabled, so PackageLookupFunction will
know exactly what casing the user requested, and
can therefore validate that casing and deny
loading the package if the casing is wrong. And
that is what would fix bazelbuild#8799

Change-Id: I46106f83c0a5b16fa347dd8a07e3c5342248c605
@philwo philwo added the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Jun 15, 2020
bazel-io pushed a commit that referenced this issue Apr 6, 2022
@lberki @copybara-github
Remove PathCasingLookupFunction.
e982f2a 
It appears not to have been wired up at all so it's all dead code.

It was created as response to #8799 about 2.5 years ago but it appears that that bug was never fixed.

RELNOTES: None.
PiperOrigin-RevId: 439766199
@github-actions
Copy link

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 2.5 years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label Mar 16, 2023
@github-actions
Copy link

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Mar 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area-Windows Windows-specific issues and feature requests P2 We'll consider working on this in future. (Assignee optional) stale Issues or PRs that are stale (no activity for 30 days) team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website type: bug
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

WIP: Add case-checking PackageIdentifier laszlocsomor/bazel
3 participants
@philwo @dslomov @laszlocsomor