Prefer statx on linux if available #65094

oxalica · 2019-10-04T10:51:36Z

This PR make metadata-related functions try to invoke statx first on Linux if available,
making std::fs::Metadata::created work on Linux with statx supported.

It follows the discussion in #61386 , and will fix #59743

The implementation of this PR is simply converting struct statx into struct stat64 with
extra fields for btime if statx succeeds, since other fields are not currently used.

I also did a separated benchmark for fs::metadata, stat64, statx, and statx with conversion to stat64.
It shows that statx with conversion is even more faster than pure statx.
I think it's due to sizeof stat64 == 114 but sizeof statx == 256.

Anyway, the bare implementation of statx with conversion is only about 0.2% slower than the original impl (stat64-family).
With heap-allocation counted (~8.5% of total cost), the difference between stat and statx (with or without conversion) is just nothing.

Therefore, I think it is not urgent to use bare struct statx as underlying representation now.
There is no need to break std::os::linux::fs::MetadataExt::as_raw_stat (#61386 (comment))

Separated bare benchmarks:

metadata_ok             time:   [529.41 ns 529.77 ns 530.19 ns]
metadata_err            time:   [538.71 ns 539.39 ns 540.35 ns]
stat64_ok               time:   [484.32 ns 484.53 ns 484.75 ns]
stat64_err              time:   [481.77 ns 482.00 ns 482.24 ns]
statx_ok                time:   [488.07 ns 488.35 ns 488.62 ns]
statx_err               time:   [487.74 ns 488.00 ns 488.27 ns]
statx_cvt_ok            time:   [485.05 ns 485.28 ns 485.53 ns]
statx_cvt_err           time:   [485.23 ns 485.45 ns 485.67 ns]

r? @alexcrichton

rust-highfive · 2019-10-04T10:51:46Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

ariasuni · 2019-10-04T19:07:13Z

I think the doc needs to be updated, see here:

The returned value corresponds to the birthtime field of stat on Unix platforms and the ftCreationTime field on Windows platforms.

It could be changed to something like:

The returned value corresponds to the btime field of statx on Linux (available since Linux 4.11), birthtime field of stat on other Unix platforms and the ftCreationTime field on Windows platforms.

alexcrichton · 2019-10-08T00:25:13Z

This is looking good to me, thanks! My main comment would be to make the platform-specific code here a bit more maintainable. Would it be possible to instead of duplicating each function only include Linux-specific code like so:

#[cfg(target_os = "linux")]
{
    // statx code...
}

// the current implementation as a fallback

That should hopefully make it a bit more clear that this is the same as the current code, only it has a Linux-specific fallback.

src/libstd/sys/unix/fs.rs

alexcrichton

Just a few final comments, but otherwise r=me, thanks!

alexcrichton · 2019-10-09T06:13:51Z

src/libstd/sys/unix/fs.rs

+            stat.st_ctime_nsec = buf.stx_ctime.tv_nsec as i64;
+
+            let extra = StatxExtraFields {
+                stx_mask: buf.stx_mask,


This stx_mask field, according to the man page, looks to indicate whether fields are actually available or not. This is used for the creation time, but should this also be taken into account for all the fields above as well? (presumably for them we'd return an error if they aren't available?)

So we need to check buf.statx_mask & STATX_BASIC_STATS == STATX_BASIC_STATS?

But what would be returned by stat64 for the case of missing basic fields?
I haven't seen anything about it in the man page of stat, including the ERRORS section.

For man page of statx,

If a filesystem does not support a field or if it has an unrepre‐
sentable value (for instance, a file with an exotic type), then the
mask bit corresponding to that field will be cleared in stx_mask even
if the user asked for it and a dummy value will be filled in for com‐
patibility purposes if one is available (e.g., a dummy UID and GID
may be specified to mount under some circumstances).

Is this the same behavior as stat which never return a "partial result"?

BTW: I tested to statx a file in mounted FAT32 filesystem which has no permission support. The result has all STATX_BASIC_STATS set in stx_mode, and the file mode, uid and gid are just what specified in mount. And stat64 also returns the dummy result without any error.

Ah ok, this sounds reasonable to me, thanks for the clarification!

src/libstd/sys/unix/fs.rs

alexcrichton · 2019-10-09T16:59:17Z

@bors: r+

bors · 2019-10-09T16:59:18Z

📌 Commit 21b4577 has been approved by alexcrichton

@alexcrichton

Prefer statx on linux if available This PR make `metadata`-related functions try to invoke `statx` first on Linux if available, making `std::fs::Metadata::created` work on Linux with `statx` supported. It follows the discussion in rust-lang#61386 , and will fix rust-lang#59743 The implementation of this PR is simply converting `struct statx` into `struct stat64` with extra fields for `btime` if `statx` succeeds, since other fields are not currently used. --- I also did a separated benchmark for `fs::metadata`, `stat64`, `statx`, and `statx` with conversion to `stat64`. It shows that `statx` with conversion is even more faster than pure `statx`. I think it's due to `sizeof stat64 == 114` but `sizeof statx == 256`. Anyway, the bare implementation of `statx` with conversion is only about 0.2% slower than the original impl (`stat64`-family). With heap-allocation counted (~8.5% of total cost), the difference between `stat` and `statx` (with or without conversion) is just nothing. Therefore, I think it is not urgent to use bare `struct statx` as underlying representation now. There is no need to break `std::os::linux::fs::MetadataExt::as_raw_stat` (rust-lang#61386 (comment)) [Separated bare benchmarks](https://gist.github.com/oxalica/c4073ecb202c599fe41b7f15f86dc79c): ``` metadata_ok time: [529.41 ns 529.77 ns 530.19 ns] metadata_err time: [538.71 ns 539.39 ns 540.35 ns] stat64_ok time: [484.32 ns 484.53 ns 484.75 ns] stat64_err time: [481.77 ns 482.00 ns 482.24 ns] statx_ok time: [488.07 ns 488.35 ns 488.62 ns] statx_err time: [487.74 ns 488.00 ns 488.27 ns] statx_cvt_ok time: [485.05 ns 485.28 ns 485.53 ns] statx_cvt_err time: [485.23 ns 485.45 ns 485.67 ns] ``` r? @alexcrichton

bors · 2019-10-10T08:01:01Z

⌛ Testing commit 21b4577 with merge c0ae792d7ff091accab2257c10fa4bd2b256ca25...

rust-highfive · 2019-10-10T08:10:33Z

The job i686-gnu-nopt of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

2019-10-10T08:09:19.8019111Z [RUSTC-TIMING] hashbrown test:false 0.984
2019-10-10T08:09:23.2127937Z error[E0308]: mismatched types
2019-10-10T08:09:23.2128761Z    --> src/libstd/sys/unix/fs.rs:101:29
2019-10-10T08:09:23.2129046Z     |
2019-10-10T08:09:23.2129519Z 101 |             stat.st_nlink = buf.stx_nlink as u64;
2019-10-10T08:09:23.2129976Z     |                             ^^^^^^^^^^^^^^^^^^^^ expected u32, found u64
2019-10-10T08:09:23.2130366Z help: you can convert an `u64` to `u32` and panic if the converted value wouldn't fit
2019-10-10T08:09:23.2130675Z     |
2019-10-10T08:09:23.2131060Z 101 |             stat.st_nlink = (buf.stx_nlink as u64).try_into().unwrap();
2019-10-10T08:09:23.2131755Z 
2019-10-10T08:09:23.2148960Z error[E0308]: mismatched types
2019-10-10T08:09:23.2149374Z    --> src/libstd/sys/unix/fs.rs:107:31
2019-10-10T08:09:23.2149664Z     |
2019-10-10T08:09:23.2149664Z     |
2019-10-10T08:09:23.2150053Z 107 |             stat.st_blksize = buf.stx_blksize as i64;
2019-10-10T08:09:23.2150504Z     |                               ^^^^^^^^^^^^^^^^^^^^^^ expected i32, found i64
2019-10-10T08:09:23.2151282Z help: you can convert an `i64` to `i32` and panic if the converted value wouldn't fit
2019-10-10T08:09:23.2151651Z     |
2019-10-10T08:09:23.2152032Z 107 |             stat.st_blksize = (buf.stx_blksize as i64).try_into().unwrap();
2019-10-10T08:09:23.2152779Z 
2019-10-10T08:09:23.2160791Z error[E0308]: mismatched types
2019-10-10T08:09:23.2161174Z    --> src/libstd/sys/unix/fs.rs:109:29
2019-10-10T08:09:23.2161450Z     |
2019-10-10T08:09:23.2161450Z     |
2019-10-10T08:09:23.2161821Z 109 |             stat.st_atime = buf.stx_atime.tv_sec;
2019-10-10T08:09:23.2162607Z     |                             ^^^^^^^^^^^^^^^^^^^^ expected i32, found i64
2019-10-10T08:09:23.2162988Z help: you can convert an `i64` to `i32` and panic if the converted value wouldn't fit
2019-10-10T08:09:23.2163312Z     |
2019-10-10T08:09:23.2163710Z 109 |             stat.st_atime = buf.stx_atime.tv_sec.try_into().unwrap();
2019-10-10T08:09:23.2165985Z 
2019-10-10T08:09:23.2173259Z error[E0308]: mismatched types
2019-10-10T08:09:23.2173627Z    --> src/libstd/sys/unix/fs.rs:110:34
2019-10-10T08:09:23.2173900Z     |
2019-10-10T08:09:23.2173900Z     |
2019-10-10T08:09:23.2174297Z 110 |             stat.st_atime_nsec = buf.stx_atime.tv_nsec as i64;
2019-10-10T08:09:23.2174756Z     |                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected i32, found i64
2019-10-10T08:09:23.2175863Z help: you can convert an `i64` to `i32` and panic if the converted value wouldn't fit
2019-10-10T08:09:23.2176195Z     |
2019-10-10T08:09:23.2176602Z 110 |             stat.st_atime_nsec = (buf.stx_atime.tv_nsec as i64).try_into().unwrap();
2019-10-10T08:09:23.2177143Z 
2019-10-10T08:09:23.2188286Z error[E0308]: mismatched types
2019-10-10T08:09:23.2189014Z    --> src/libstd/sys/unix/fs.rs:111:29
2019-10-10T08:09:23.2189294Z     |
2019-10-10T08:09:23.2189294Z     |
2019-10-10T08:09:23.2189667Z 111 |             stat.st_mtime = buf.stx_mtime.tv_sec;
2019-10-10T08:09:23.2190105Z     |                             ^^^^^^^^^^^^^^^^^^^^ expected i32, found i64
2019-10-10T08:09:23.2190768Z help: you can convert an `i64` to `i32` and panic if the converted value wouldn't fit
2019-10-10T08:09:23.2191074Z     |
2019-10-10T08:09:23.2191450Z 111 |             stat.st_mtime = buf.stx_mtime.tv_sec.try_into().unwrap();
2019-10-10T08:09:23.2192064Z 
2019-10-10T08:09:23.2199887Z error[E0308]: mismatched types
2019-10-10T08:09:23.2204638Z    --> src/libstd/sys/unix/fs.rs:112:34
2019-10-10T08:09:23.2206795Z     |
2019-10-10T08:09:23.2206795Z     |
2019-10-10T08:09:23.2207510Z 112 |             stat.st_mtime_nsec = buf.stx_mtime.tv_nsec as i64;
2019-10-10T08:09:23.2208255Z     |                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected i32, found i64
2019-10-10T08:09:23.2209030Z help: you can convert an `i64` to `i32` and panic if the converted value wouldn't fit
2019-10-10T08:09:23.2209544Z     |
2019-10-10T08:09:23.2210188Z 112 |             stat.st_mtime_nsec = (buf.stx_mtime.tv_nsec as i64).try_into().unwrap();
2019-10-10T08:09:23.2211077Z 
2019-10-10T08:09:23.2211745Z error[E0308]: mismatched types
2019-10-10T08:09:23.2212286Z    --> src/libstd/sys/unix/fs.rs:113:29
2019-10-10T08:09:23.2212772Z     |
2019-10-10T08:09:23.2212772Z     |
2019-10-10T08:09:23.2213476Z 113 |             stat.st_ctime = buf.stx_ctime.tv_sec;
2019-10-10T08:09:23.2214063Z     |                             ^^^^^^^^^^^^^^^^^^^^ expected i32, found i64
2019-10-10T08:09:23.2214626Z help: you can convert an `i64` to `i32` and panic if the converted value wouldn't fit
2019-10-10T08:09:23.2216148Z     |
2019-10-10T08:09:23.2216774Z 113 |             stat.st_ctime = buf.stx_ctime.tv_sec.try_into().unwrap();
2019-10-10T08:09:23.2217633Z 
2019-10-10T08:09:23.2218103Z error[E0308]: mismatched types
2019-10-10T08:09:23.2218775Z    --> src/libstd/sys/unix/fs.rs:114:34
2019-10-10T08:09:23.2219449Z     |
2019-10-10T08:09:23.2219449Z     |
2019-10-10T08:09:23.2220017Z 114 |             stat.st_ctime_nsec = buf.stx_ctime.tv_nsec as i64;
2019-10-10T08:09:23.2220688Z     |                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected i32, found i64
2019-10-10T08:09:23.2221282Z help: you can convert an `i64` to `i32` and panic if the converted value wouldn't fit
2019-10-10T08:09:23.2221784Z     |
2019-10-10T08:09:23.2222378Z 114 |             stat.st_ctime_nsec = (buf.stx_ctime.tv_nsec as i64).try_into().unwrap();
2019-10-10T08:09:23.2223835Z 
2019-10-10T08:09:23.5100574Z error: aborting due to 8 previous errors
2019-10-10T08:09:23.5142941Z 
2019-10-10T08:09:23.5143943Z For more information about this error, try `rustc --explain E0308`.
---
2019-10-10T08:09:23.5700155Z == clock drift check ==
2019-10-10T08:09:23.5715859Z   local time: Thu Oct 10 08:09:23 UTC 2019
2019-10-10T08:09:23.8416114Z   network time: Thu, 10 Oct 2019 08:09:23 GMT
2019-10-10T08:09:23.8417045Z == end clock drift check ==
2019-10-10T08:09:25.4838511Z ##[error]Bash exited with code '1'.
2019-10-10T08:09:25.4875507Z ##[section]Starting: Upload CPU usage statistics
2019-10-10T08:09:25.4878983Z ==============================================================================
2019-10-10T08:09:25.4879078Z Task         : Bash
2019-10-10T08:09:25.4879190Z Description  : Run a Bash script on macOS, Linux, or Windows

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

bors · 2019-10-10T08:10:45Z

💔 Test failed - checks-azure

oxalica · 2019-10-10T09:09:29Z

Fixed type conversions from statx to stat64. It should work on 32bit platform now.

Also squashed and rebased to master.

@alexcrichton

alexcrichton · 2019-10-10T16:05:55Z

@bors: r+

bors · 2019-10-10T16:05:56Z

📌 Commit 4c56b1c2f3b881789d84df26f4366994983f8212 has been approved by alexcrichton

bors · 2019-10-10T19:30:28Z

⌛ Testing commit 4c56b1c2f3b881789d84df26f4366994983f8212 with merge 550eb83a2f5ed85655cffa2a221b6198bdc480d8...

rust-highfive · 2019-10-10T19:40:30Z

The job i686-apple of your PR failed (pretty log, raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.

2019-10-10T19:39:14.8311030Z [RUSTC-TIMING] panic_unwind test:false 0.442
2019-10-10T19:39:15.6477540Z [RUSTC-TIMING] alloc test:false 6.897
2019-10-10T19:39:16.0165130Z [RUSTC-TIMING] hashbrown test:false 1.559
2019-10-10T19:39:16.4833620Z [RUSTC-TIMING] core test:false 40.167
2019-10-10T19:39:17.6837950Z error[E0412]: cannot find type `statx_timestamp` in crate `libc`
2019-10-10T19:39:17.6839040Z   --> src/libstd/sys/unix/fs.rs:55:22
2019-10-10T19:39:17.6839840Z    |
2019-10-10T19:39:17.6840600Z 55 |     stx_btime: libc::statx_timestamp,
2019-10-10T19:39:17.6841450Z    |                      ^^^^^^^^^^^^^^^ not found in `libc`
2019-10-10T19:39:21.4701030Z error: aborting due to previous error
2019-10-10T19:39:21.4701330Z 
2019-10-10T19:39:21.4702090Z For more information about this error, try `rustc --explain E0412`.
2019-10-10T19:39:21.5660190Z [RUSTC-TIMING] std test:false 5.059
---
2019-10-10T19:39:21.5890870Z == clock drift check ==
2019-10-10T19:39:21.5951760Z   local time: Thu Oct 10 19:39:21 UTC 2019
2019-10-10T19:39:21.6333750Z   network time: Thu, 10 Oct 2019 19:39:21 GMT
2019-10-10T19:39:21.6336280Z == end clock drift check ==
2019-10-10T19:39:21.6520630Z ##[error]Bash exited with code '1'.
2019-10-10T19:39:21.6575060Z ##[section]Starting: Upload CPU usage statistics
2019-10-10T19:39:21.6580530Z ==============================================================================
2019-10-10T19:39:21.6580660Z Task         : Bash
2019-10-10T19:39:21.6580740Z Description  : Run a Bash script on macOS, Linux, or Windows

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

bors · 2019-10-17T14:30:21Z

📌 Commit c3bbdc5 has been approved by alexcrichton

@alexcrichton

Prefer statx on linux if available This PR make `metadata`-related functions try to invoke `statx` first on Linux if available, making `std::fs::Metadata::created` work on Linux with `statx` supported. It follows the discussion in rust-lang#61386 , and will fix rust-lang#59743 The implementation of this PR is simply converting `struct statx` into `struct stat64` with extra fields for `btime` if `statx` succeeds, since other fields are not currently used. --- I also did a separated benchmark for `fs::metadata`, `stat64`, `statx`, and `statx` with conversion to `stat64`. It shows that `statx` with conversion is even more faster than pure `statx`. I think it's due to `sizeof stat64 == 114` but `sizeof statx == 256`. Anyway, the bare implementation of `statx` with conversion is only about 0.2% slower than the original impl (`stat64`-family). With heap-allocation counted (~8.5% of total cost), the difference between `stat` and `statx` (with or without conversion) is just nothing. Therefore, I think it is not urgent to use bare `struct statx` as underlying representation now. There is no need to break `std::os::linux::fs::MetadataExt::as_raw_stat` (rust-lang#61386 (comment)) [Separated bare benchmarks](https://gist.github.com/oxalica/c4073ecb202c599fe41b7f15f86dc79c): ``` metadata_ok time: [529.41 ns 529.77 ns 530.19 ns] metadata_err time: [538.71 ns 539.39 ns 540.35 ns] stat64_ok time: [484.32 ns 484.53 ns 484.75 ns] stat64_err time: [481.77 ns 482.00 ns 482.24 ns] statx_ok time: [488.07 ns 488.35 ns 488.62 ns] statx_err time: [487.74 ns 488.00 ns 488.27 ns] statx_cvt_ok time: [485.05 ns 485.28 ns 485.53 ns] statx_cvt_err time: [485.23 ns 485.45 ns 485.67 ns] ``` r? @alexcrichton

Centril · 2019-10-18T00:07:04Z

Failed in #65530 (comment), @bors r- rollup=never

oxalica · 2019-10-18T02:35:52Z

@alexcrichton
Squashed previous commits and rebased to master.
Fixed cast of stx_btime.tv_nsec.

alexcrichton · 2019-10-18T05:14:37Z

@bors: r+

bors · 2019-10-18T05:14:38Z

📌 Commit 2ee45c9 has been approved by alexcrichton

bors · 2019-10-19T22:01:35Z

⌛ Testing commit 2ee45c9 with merge 22eec92...

@alexcrichton

Prefer statx on linux if available This PR make `metadata`-related functions try to invoke `statx` first on Linux if available, making `std::fs::Metadata::created` work on Linux with `statx` supported. It follows the discussion in #61386 , and will fix #59743 The implementation of this PR is simply converting `struct statx` into `struct stat64` with extra fields for `btime` if `statx` succeeds, since other fields are not currently used. --- I also did a separated benchmark for `fs::metadata`, `stat64`, `statx`, and `statx` with conversion to `stat64`. It shows that `statx` with conversion is even more faster than pure `statx`. I think it's due to `sizeof stat64 == 114` but `sizeof statx == 256`. Anyway, the bare implementation of `statx` with conversion is only about 0.2% slower than the original impl (`stat64`-family). With heap-allocation counted (~8.5% of total cost), the difference between `stat` and `statx` (with or without conversion) is just nothing. Therefore, I think it is not urgent to use bare `struct statx` as underlying representation now. There is no need to break `std::os::linux::fs::MetadataExt::as_raw_stat` (#61386 (comment)) [Separated bare benchmarks](https://gist.github.com/oxalica/c4073ecb202c599fe41b7f15f86dc79c): ``` metadata_ok time: [529.41 ns 529.77 ns 530.19 ns] metadata_err time: [538.71 ns 539.39 ns 540.35 ns] stat64_ok time: [484.32 ns 484.53 ns 484.75 ns] stat64_err time: [481.77 ns 482.00 ns 482.24 ns] statx_ok time: [488.07 ns 488.35 ns 488.62 ns] statx_err time: [487.74 ns 488.00 ns 488.27 ns] statx_cvt_ok time: [485.05 ns 485.28 ns 485.53 ns] statx_cvt_err time: [485.23 ns 485.45 ns 485.67 ns] ``` r? @alexcrichton

bors · 2019-10-20T01:59:53Z

☀️ Test successful - checks-azure
Approved by: alexcrichton
Pushing 22eec92 to master...

jethrogb · 2019-10-21T11:03:31Z

I think this might be broken on some filesystems on Linux. Simple fs::exists calls stopped working for me when using Docker.

jethrogb · 2019-10-21T11:23:57Z

Actually, I think docker may have a cgroup or BPF filter or so installed that returns EPERM on non-whitelisted syscalls. This prevents the fallback from operating, because that only triggers on ENOSYS.

Host kernel: 4.15.0-65-generic

docker version

Client:
 Version:      17.03.2-ce
 API version:  1.27
 Go version:   go1.6.2
 Git commit:   f5ec1e2
 Built:        Thu Jul  5 23:07:48 2018
 OS/Arch:      linux/amd64

Server:
 Version:      17.03.2-ce
 API version:  1.27 (minimum version 1.12)
 Go version:   go1.6.2
 Git commit:   f5ec1e2
 Built:        Thu Jul  5 23:07:48 2018
 OS/Arch:      linux/amd64
 Experimental: false

$ docker run --rm -it ubuntu:xenial
# apt update
# apt install wget
# wget https://sh.rustup.rs -O rustup.sh
# chmod ugo+x rustup.sh 
# ./rustup.sh -y --default-toolchain nightly
# source $HOME/.cargo/env
# rustc -vV
rustc 1.40.0-nightly (7979016af 2019-10-20)
binary: rustc
commit-hash: 7979016aff545f7b41cc517031026020b340989d
commit-date: 2019-10-20
host: x86_64-unknown-linux-gnu
release: 1.40.0-nightly
error: failed to find a `codegen-backends` folder in the sysroot candidates:
* /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu
* /root/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu

@alexcrichton

Try statx for all linux-gnu target. After rust-lang/libc#1577, which is contained in `libc` 0.2.66, provides `SYS_statx` for all Linux platform, so we can try to use `statx` for ~all Linux target~ all linux-gnu targets. Unfortunately, `struct statx` and `fn statx` is not a part of public interface of musl (currently), ~we still need to invoke it through `syscall`~ we does **not** support statx for musl or other libc impls currently. Previous PR: rust-lang#65094 cc @alexcrichton

rust-highfive assigned alexcrichton Oct 4, 2019

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 4, 2019

ariasuni reviewed Oct 8, 2019

View reviewed changes

src/libstd/sys/unix/fs.rs Outdated Show resolved Hide resolved

alexcrichton reviewed Oct 9, 2019

View reviewed changes

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 9, 2019

Centril mentioned this pull request Oct 9, 2019

Rollup of 4 pull requests #65243

Closed

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 10, 2019

oxalica force-pushed the linux-statx branch from 21b4577 to 4c56b1c Compare October 10, 2019 09:06

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 10, 2019

Centril mentioned this pull request Oct 17, 2019

Rollup of 7 pull requests #65530

Closed

bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Oct 18, 2019

oxalica added 3 commits October 18, 2019 10:32

Prefer statx on linux if available

43f398b

Fix cfgs for current libc

15cb3e0

Fix cast of stx_btime.tv_nsec

2ee45c9

oxalica force-pushed the linux-statx branch from c3bbdc5 to 2ee45c9 Compare October 18, 2019 02:34

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 18, 2019

bors added the merged-by-bors This PR was explicitly merged by bors. label Oct 20, 2019

bors merged commit 2ee45c9 into rust-lang:master Oct 20, 2019

oxalica deleted the linux-statx branch October 20, 2019 03:06

ariasuni mentioned this pull request Oct 20, 2019

Use statx to get creation time of files on Linux ogham/exa#591

Closed

jethrogb mentioned this pull request Oct 21, 2019

Compiler doesn't work when using Docker #65662

Closed

ariasuni mentioned this pull request Nov 24, 2019

"creation time is not available on this platform currently" ogham/exa#576

Closed

oxalica mentioned this pull request Jan 1, 2020

Try statx for all linux-gnu target. #67774

Merged

mrkline mentioned this pull request Jan 13, 2020

Don't make assumptions about Metadata based on temp_dir ogham/exa#622

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Prefer statx on linux if available #65094

Prefer statx on linux if available #65094

oxalica commented Oct 4, 2019

rust-highfive commented Oct 4, 2019

ariasuni commented Oct 4, 2019

alexcrichton commented Oct 8, 2019

alexcrichton left a comment

alexcrichton Oct 9, 2019

oxalica Oct 9, 2019

alexcrichton Oct 9, 2019

alexcrichton commented Oct 9, 2019

bors commented Oct 9, 2019

bors commented Oct 10, 2019

rust-highfive commented Oct 10, 2019

bors commented Oct 10, 2019

oxalica commented Oct 10, 2019

alexcrichton commented Oct 10, 2019

bors commented Oct 10, 2019

bors commented Oct 10, 2019

rust-highfive commented Oct 10, 2019

bors commented Oct 17, 2019

Centril commented Oct 18, 2019

oxalica commented Oct 18, 2019

alexcrichton commented Oct 18, 2019

bors commented Oct 18, 2019

bors commented Oct 19, 2019

bors commented Oct 20, 2019

jethrogb commented Oct 21, 2019

jethrogb commented Oct 21, 2019

Prefer statx on linux if available #65094

Prefer statx on linux if available #65094

Conversation

oxalica commented Oct 4, 2019

rust-highfive commented Oct 4, 2019

ariasuni commented Oct 4, 2019

alexcrichton commented Oct 8, 2019

alexcrichton left a comment

Choose a reason for hiding this comment

alexcrichton Oct 9, 2019

Choose a reason for hiding this comment

oxalica Oct 9, 2019

Choose a reason for hiding this comment

alexcrichton Oct 9, 2019

Choose a reason for hiding this comment

alexcrichton commented Oct 9, 2019

bors commented Oct 9, 2019

bors commented Oct 10, 2019

rust-highfive commented Oct 10, 2019

bors commented Oct 10, 2019

oxalica commented Oct 10, 2019

alexcrichton commented Oct 10, 2019

bors commented Oct 10, 2019

bors commented Oct 10, 2019

rust-highfive commented Oct 10, 2019

bors commented Oct 17, 2019

Centril commented Oct 18, 2019

oxalica commented Oct 18, 2019

alexcrichton commented Oct 18, 2019

bors commented Oct 18, 2019

bors commented Oct 19, 2019

bors commented Oct 20, 2019

jethrogb commented Oct 21, 2019

jethrogb commented Oct 21, 2019