tidy on NTFS spuriously warns about executable bit

[scrabsha]

When I run ./x.py tidy, I get a lot of errors:

$ ./x.py test tidy
Updating only changed submodules
Submodules updated in 0.02 seconds
    Finished dev [unoptimized + debuginfo] target(s) in 0.15s
Building stage0 tool tidy (x86_64-unknown-linux-gnu)
    Finished release [optimized + debuginfo] target(s) in 0.14s
tidy check
* 615 error codes
* highest error code: E0772
Checking which error codes lack tests...
Found 509 error codes
Found 0 error codes with no tests
Done!
tidy error: binary checked into source: /mnt/rust/src/librustc_errors/annotate_snippet_emitter_writer.rs
tidy error: binary checked into source: /mnt/rust/src/librustc_errors/Cargo.toml
tidy error: binary checked into source: /mnt/rust/src/librustc_errors/diagnostic.rs
tidy error: binary checked into source: /mnt/rust/src/librustc_errors/diagnostic_builder.rs
tidy error: binary checked into source: /mnt/rust/src/librustc_errors/emitter.rs
tidy error: binary checked into source: /mnt/rust/src/librustc_errors/json/tests.rs
tidy error: binary checked into source: /mnt/rust/src/librustc_errors/json.rs
tidy error: binary checked into source: /mnt/rust/src/librustc_errors/lib.rs
tidy error: binary checked into source: /mnt/rust/src/librustc_errors/lock.rs
tidy error: binary checked into source: /mnt/rust/src/librustc_errors/registry.rs
tidy error: binary checked into source: /mnt/rust/src/librustc_errors/snippet.rs
tidy error: binary checked into source: /mnt/rust/src/librustc_errors/styled_buffer.rs
tidy error: binary checked into source: /mnt/rust/src/librustc_middle/arena.rs
tidy error: binary checked into source: /mnt/rust/src/librustc_middle/benches/lib.rs
tidy error: binary checked into source: /mnt/rust/src/librustc_middle/Cargo.toml
tidy error: binary checked into source: /mnt/rust/src/librustc_middle/dep_graph/dep_node.rs

(Followed by about 22900 similar errors).

I reported the issue on URLO. @daboross found where in the code the error is emitted (here). According to them, the error comes from the fact I am running ./x.py test tidy on a NTFS partition on Linux (see their comment).

[Mark-Simulacrum]

Yeah, this sounds like not something we'd previously encountered.

I am happy to accept a patch adding detection for NTFS, if there's a good way to do that. I'm not sure myself how to go about detecting that.

[mati865]

Like I said in #74753 (comment) using blacklist based on /proc/version should be replaced with a check whether FS has proper permissions.

[scrabsha]

I am happy to accept a patch adding detection for NTFS, if there's a good way to do that. I'm not sure myself how to go about detecting that.

As far as I know, sysinfo allows to detect mounted partitions and is cross-platform. It would allow us to create a hashmap of mount point -> FS type. Then, calling Path::ancestors and doing a lookup to the hashmap would allow us to find the partition type in which the whole rust repository is located.

This applies for Linux for sure, but maybe other UNIXes.

Like I said in #74753 (comment) using blacklist based on /proc/version should be replaced with a check whether FS has proper permissions.

I am not aware of a way to check if a given filesystem has proper permission. IMO the simplest way to do so is to check if the FS name is any of FAT32, NTFS, and others.

[Enselic]

Triage: Is this still a problem?