Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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
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)
charliermarsh added a commit to astral-sh/tokio-tar that referenced this pull request Feb 5, 2025
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