-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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.
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
Add support for pre-unix-epoch file dates on Apple platforms (#108277) #117451
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
O-unix
Operating system: Unix-like
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
labels
Oct 31, 2023
Byron
force-pushed
the
issue-108277-apple-fix
branch
from
October 31, 2023 14:57
0f9e3f2
to
aa806d6
Compare
Urgau
reviewed
Oct 31, 2023
…ng#108277) Time in UNIX system calls counts from the epoch, 1970-01-01. The timespec struct used in various system calls represents this as a number of seconds and a number of nanoseconds. Nanoseconds are required to be between 0 and 999_999_999, because the portion outside that range should be represented in the seconds field; if nanoseconds were larger than 999_999_999, the seconds field should go up instead. Suppose you ask for the time 1969-12-31, what time is that? On UNIX systems that support times before the epoch, that's seconds=-86400, one day before the epoch. But now, suppose you ask for the time 1969-12-31 23:59:00.1. In other words, a tenth of a second after one minute before the epoch. On most UNIX systems, that's represented as seconds=-60, nanoseconds=100_000_000. The macOS bug is that it returns seconds=-59, nanoseconds=-900_000_000. While that's in some sense an accurate description of the time (59.9 seconds before the epoch), that violates the invariant of the timespec data structure: nanoseconds must be between 0 and 999999999. This causes this assertion in the Rust standard library. So, on macOS, if we get a Timespec value with seconds less than or equal to zero, and nanoseconds between -999_999_999 and -1 (inclusive), we can add 1_000_000_000 to the nanoseconds and subtract 1 from the seconds, and then convert. The resulting timespec value is still accepted by macOS, and when fed back into the OS, produces the same results. (If you set a file's mtime with that timestamp, then read it back, you get back the one with negative nanoseconds again.) Co-authored-by: Josh Triplett <josh@joshtriplett.org>
Byron
force-pushed
the
issue-108277-apple-fix
branch
from
October 31, 2023 16:01
aa806d6
to
a8ece11
Compare
@bors r+ rollup |
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 31, 2023
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 31, 2023
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#113241 (rustdoc: Document lack of object safety on affected traits) - rust-lang#117388 (Turn const_caller_location from a query to a hook) - rust-lang#117417 (Add a stable MIR visitor) - rust-lang#117439 (prepopulate opaque ty storage before using it) - rust-lang#117451 (Add support for pre-unix-epoch file dates on Apple platforms (rust-lang#108277)) r? `@ghost` `@rustbot` modify labels: rollup
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 31, 2023
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#113241 (rustdoc: Document lack of object safety on affected traits) - rust-lang#117388 (Turn const_caller_location from a query to a hook) - rust-lang#117417 (Add a stable MIR visitor) - rust-lang#117439 (prepopulate opaque ty storage before using it) - rust-lang#117451 (Add support for pre-unix-epoch file dates on Apple platforms (rust-lang#108277)) r? `@ghost` `@rustbot` modify labels: rollup
rust-timer
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Nov 1, 2023
Rollup merge of rust-lang#117451 - Byron:issue-108277-apple-fix, r=joshtriplett Add support for pre-unix-epoch file dates on Apple platforms (rust-lang#108277) Please note that even though the assertion being hit is the same on MacOS and thus similar to what's described in rust-lang#108277, on MacOS it's possible to convert the numbers such that they are valid, don't hit the assertion and are round-trippable. Doing so effectively fixes the issue on Apple platforms. This PR does not attempt to harden other platforms against negative nanoseconds, which can happen for many reasons including mild filesystem corruption. ---- Time in UNIX system calls counts from the epoch, 1970-01-01. The timespec struct used in various system calls represents this as a number of seconds and a number of nanoseconds. Nanoseconds are required to be between 0 and 999_999_999, because the portion outside that range should be represented in the seconds field; if nanoseconds were larger than 999_999_999, the seconds field should go up instead. Suppose you ask for the time 1969-12-31, what time is that? On UNIX systems that support times before the epoch, that's seconds=-86400, one day before the epoch. But now, suppose you ask for the time 1969-12-31 23:59:00.1. In other words, a tenth of a second after one minute before the epoch. On most UNIX systems, that's represented as seconds=-60, nanoseconds=100_000_000. The macOS bug is that it returns seconds=-59, nanoseconds=-900_000_000. While that's in some sense an accurate description of the time (59.9 seconds before the epoch), that violates the invariant of the timespec data structure: nanoseconds must be between 0 and 999999999. This causes this assertion in the Rust standard library. So, on macOS, if we get a Timespec value with seconds less than or equal to zero, and nanoseconds between -999_999_999 and -1 (inclusive), we can add 1_000_000_000 to the nanoseconds and subtract 1 from the seconds, and then convert. The resulting timespec value is still accepted by macOS, and when fed back into the OS, produces the same results. (If you set a file's mtime with that timestamp, then read it back, you get back the one with negative nanoseconds again.) Co-authored-by: Josh Triplett <josh@joshtriplett.org>
bors-ferrocene bot
added a commit
to ferrocene/ferrocene
that referenced
this pull request
Nov 1, 2023
78: Automated pull from upstream `master` r=tshepang a=github-actions[bot] This PR pulls the following changes from the upstream repository: * rust-lang/rust#113970 * rust-lang/rust#117459 * rust-lang/rust#117451 * rust-lang/rust#117439 * rust-lang/rust#117417 * rust-lang/rust#117388 * rust-lang/rust#113241 * rust-lang/rust#117462 * rust-lang/rust#117450 * rust-lang/rust#117407 * rust-lang/rust#117444 * rust-lang/rust#117438 * rust-lang/rust#117421 * rust-lang/rust#117416 * rust-lang/rust#116712 * rust-lang/rust#116267 * rust-lang/rust#117377 * rust-lang/rust#117419 Co-authored-by: Alexis (Poliorcetics) Bourget <ab_github@poliorcetiq.eu> Co-authored-by: Esteban Küber <esteban@kuber.com.ar> Co-authored-by: David Tolnay <dtolnay@gmail.com> Co-authored-by: Celina G. Val <celinval@amazon.com> Co-authored-by: Michael Goulet <michael@errs.io> Co-authored-by: bors <bors@rust-lang.org> Co-authored-by: Camille GILLOT <gillot.camille@gmail.com> Co-authored-by: lcnr <rust@lcnr.de> Co-authored-by: Zalathar <Zalathar@users.noreply.github.com> Co-authored-by: Oli Scherer <git-spam-no-reply9815368754983@oli-obk.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
O-unix
Operating system: Unix-like
S-waiting-on-bors
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
T-libs
Relevant to the library team, which will review and decide on the PR/issue.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please note that even though the assertion being hit is the same on MacOS and thus similar to what's described in #108277, on MacOS it's possible to convert the numbers such that they are valid, don't hit the assertion and are round-trippable.
Doing so effectively fixes the issue on Apple platforms.
This PR does not attempt to harden other platforms against negative nanoseconds, which can happen for many reasons including mild filesystem corruption.
Time in UNIX system calls counts from the epoch, 1970-01-01. The timespec
struct used in various system calls represents this as a number of seconds and
a number of nanoseconds. Nanoseconds are required to be between 0 and
999_999_999, because the portion outside that range should be represented in
the seconds field; if nanoseconds were larger than 999_999_999, the seconds
field should go up instead.
Suppose you ask for the time 1969-12-31, what time is that? On UNIX systems
that support times before the epoch, that's seconds=-86400, one day before the
epoch. But now, suppose you ask for the time 1969-12-31 23:59:00.1. In other
words, a tenth of a second after one minute before the epoch. On most UNIX
systems, that's represented as seconds=-60, nanoseconds=100_000_000. The macOS
bug is that it returns seconds=-59, nanoseconds=-900_000_000.
While that's in some sense an accurate description of the time (59.9 seconds
before the epoch), that violates the invariant of the timespec data structure:
nanoseconds must be between 0 and 999999999. This causes this assertion in the
Rust standard library.
So, on macOS, if we get a Timespec value with seconds less than or equal to
zero, and nanoseconds between -999_999_999 and -1 (inclusive), we can add
1_000_000_000 to the nanoseconds and subtract 1 from the seconds, and then
convert. The resulting timespec value is still accepted by macOS, and when fed
back into the OS, produces the same results. (If you set a file's mtime with
that timestamp, then read it back, you get back the one with negative
nanoseconds again.)
Co-authored-by: Josh Triplett josh@joshtriplett.org