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.

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

Unify mtime constant used on Unix and Windows #346

Merged
merged 2 commits into from
Jun 4, 2024
Merged

Unify mtime constant used on Unix and Windows #346

merged 2 commits into from
Jun 4, 2024

Conversation

mkaput
Copy link
Contributor

@mkaput mkaput commented Nov 13, 2023

fix #341

Copy link
Collaborator

@cgwalters cgwalters left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's clearly no reason for them to be different. However, I do have a lingering concern here that some projects may be e.g. checksumming the result of the tar stream produced by HeaderMode::Deterministic and so this could break them.

I'm personally tentatively OK with changing this, but can you hoist this to a const ARBITRARY_DETERMINISTIC_TIMESTAMP that is explicitly shared?

We may also want to consider e.g.

#[cfg(windows)]
pub const PREVIOUS_DETERMINISTIC_TIMESTAMP: <old value>
#[cfg(unix)
pub const PREVIOUS_DETERMINISTIC_TIMESTAMP: <current value>

or so so that anyone who is bit by this can explicitly still use HeaderMode::Deterministic but then also override the time back to the previous value?

@mkaput
Copy link
Contributor Author

mkaput commented Jun 4, 2024

I'm personally tentatively OK with changing this, but can you hoist this to a const ARBITRARY_DETERMINISTIC_TIMESTAMP that is explicitly shared?

Done

We may also want to consider e.g.

#[cfg(windows)]
pub const PREVIOUS_DETERMINISTIC_TIMESTAMP: <old value>
#[cfg(unix)
pub const PREVIOUS_DETERMINISTIC_TIMESTAMP: <current value>

or so so that anyone who is bit by this can explicitly still use HeaderMode::Deterministic but then also override the time back to the previous value?

I feel uneasy with this because:

  1. This makes something that used to be a bug, soon to be fixed, a public API (?) Looks contradictory.
  2. If somebody heavily relied on these values, then this means they made them part of their public interface (i.e. they leaked tar-rs implementation detail as their public thing). So this looks like a problem of the user that tar-rs should not worry about?
  3. This change is worthy of a breaking release anyway, I believe?
  4. This crate also supports other targets (wasm32), for which such constant does not exist.

@mkaput
Copy link
Contributor Author

mkaput commented Jun 4, 2024

For context, that's how I reacted to this problem in the project I stumbled upon this:
https://github.com/software-mansion/scarb/blob/fc81b059a81d164c88eaed021a7b84c63fee5d00/scarb/src/ops/package.rs#L456-L466

@cgwalters cgwalters mentioned this pull request Jun 4, 2024
@cgwalters
Copy link
Collaborator

Right. Actually if we were breaking semver I'd argue HeaderMode::Deterministic should become HeaderMode::Deterministic { mtime: u64 } - and callers should pass their own timestamp. This is e.g. what I do in https://github.com/coreos/cargo-vendor-filterer/blob/28c7760484240184c95f76b5a3f11d92a6779ff1/src/main.rs#L492 which ultimately takes the timestamp from the git commit, as is recommended by https://reproducible-builds.org/docs/source-date-epoch/

@mkaput
Copy link
Contributor Author

mkaput commented Jun 4, 2024

Right. Actually if we were breaking semver I'd argue HeaderMode::Deterministic should become HeaderMode::Deterministic { mtime: u64 } - and callers should pass their own timestamp. This is e.g. what I do in https://github.com/coreos/cargo-vendor-filterer/blob/28c7760484240184c95f76b5a3f11d92a6779ff1/src/main.rs#L492 which ultimately takes the timestamp from the git commit, as is recommended by https://reproducible-builds.org/docs/source-date-epoch/

That sounds like the smartest move because it would force people to reason about that timestamp.

@alexcrichton
Copy link
Owner

Thanks for the PR (and sticking it out through the delay @mkaput) and thanks for the review @cgwalters!

@alexcrichton alexcrichton merged commit dd9123c into alexcrichton:main Jun 4, 2024
7 checks passed
cgwalters added a commit to cgwalters/tar-rs that referenced this pull request Jun 4, 2024
There's only one notable change here, which is that
`Header::Deterministic` on Windows now uses the same timestamp
as is used on Unix.  If this breaks your use case, please
let us know in alexcrichton#346

Besides that, there's a few testing, documentation, and internal
cleanups.
cgwalters added a commit to cgwalters/tar-rs that referenced this pull request Jun 4, 2024
There's only one notable change here, which is that
`Header::Deterministic` on Windows now uses the same timestamp
as is used on Unix.  If this breaks your use case, please
let us know in alexcrichton#346

Besides that, there's a few testing, documentation, and internal
cleanups.  We're hoping to continue to merge PRs and address
issues; this release is small but is intending to maintain
momentum.

Signed-off-by: Colin Walters <[email protected]>
@cgwalters cgwalters mentioned this pull request Jun 4, 2024
@mkaput mkaput deleted the set-mtime-deterministic branch June 4, 2024 19:08
alexcrichton pushed a commit that referenced this pull request Jun 4, 2024
There's only one notable change here, which is that
`Header::Deterministic` on Windows now uses the same timestamp
as is used on Unix.  If this breaks your use case, please
let us know in #346

Besides that, there's a few testing, documentation, and internal
cleanups.  We're hoping to continue to merge PRs and address
issues; this release is small but is intending to maintain
momentum.

Signed-off-by: Colin Walters <[email protected]>
ararslan pushed a commit to ararslan/binstall-tar that referenced this pull request Jun 6, 2024
* Unify `mtime` constant used on Unix and Windows

fix alexcrichton#341

* Extract `DETERMINISTIC_TIMESTAMP`

(cherry picked from commit dd9123c)
ararslan pushed a commit to ararslan/binstall-tar that referenced this pull request Jun 6, 2024
There's only one notable change here, which is that
`Header::Deterministic` on Windows now uses the same timestamp
as is used on Unix.  If this breaks your use case, please
let us know in alexcrichton#346

Besides that, there's a few testing, documentation, and internal
cleanups.  We're hoping to continue to merge PRs and address
issues; this release is small but is intending to maintain
momentum.

Signed-off-by: Colin Walters <[email protected]>
(cherry picked from commit 2cb0c7b)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

HeaderMode::Deterministic differs in behaviour on Unix and Windows platforms
3 participants