testEnumerateFileStores enumerates FileSystems.getDefault().getFileStores(), 
puts them in a HashSet and asserts the sizes match. In a container run it saw 
35 stores but 34 unique.

Two identical entries in /proc/mounts produce two UnixFileStore objects that 
compare equal (equals requires dev, mount dir and name to all match), so the 
HashSet collapses them.

The test already guards against this with 
assumeTrue(FileUtils.areMountPointsAccessibleAndUnique()), but that helper runs 
plain `df`, which lists only a subset of mounted file systems - in the failing 
run `df` reported 4 file systems while the JDK enumerated 35 - so it cannot see 
the duplicates the test then asserts on.

Reproduced by creating a duplicate mount in a container:
mkdir -p /mnt/dup
mount --bind /mnt/dup /mnt/dup
mount --bind /mnt/dup /mnt/dup

/proc/mounts then holds two identical entries; `df` matches neither, `df -a` 
matches both. With that in place, only the flag differing:
df    -> jtreg FileStore/Basic.java: failed: 1
df -a -> jtreg FileStore/Basic.java: passed: 1 (assumption fires, 
testEnumerateFileStores skipped, other four subtests still run)

The @implNote is updated to match.
areFileSystemsAccessible() above also uses plain `df` while documenting itself 
as checking "all mounted file systems"; left unchanged to keep this minimal, 
but it may deserve the same fix.

---------
- [x] I confirm that I make this contribution in accordance with the [OpenJDK 
Interim AI Policy](https://openjdk.org/legal/ai).

-------------

Commit messages:
 - 8389110: java/nio/file/FileStore/Basic.java testEnumerateFileStores fails in 
container: FileStores should be unique

Changes: https://git.openjdk.org/jdk/pull/32091/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=32091&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8389110
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/32091.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/32091/head:pull/32091

PR: https://git.openjdk.org/jdk/pull/32091

Reply via email to