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

HeaderMode::Deterministic differs in behaviour on Unix and Windows platforms #341

Closed
abizjak opened this issue Oct 26, 2023 · 0 comments · Fixed by #346
Closed

HeaderMode::Deterministic differs in behaviour on Unix and Windows platforms #341

abizjak opened this issue Oct 26, 2023 · 0 comments · Fixed by #346

Comments

@abizjak
Copy link

abizjak commented Oct 26, 2023

On Windows the mtime is set to the dummy value of https://github.com/alexcrichton/tar-rs/blob/master/src/header.rs#L828

                self.set_mtime(123456789); // see above in unix

but on Unix it is set to https://github.com/alexcrichton/tar-rs/blob/master/src/header.rs#L760

                // We could in theory set the mtime to zero here, but not all
                // tools seem to behave well when ingesting files with a 0
                // timestamp. For example rust-lang/cargo#9512 shows that lldb
                // doesn't ingest files with a zero timestamp correctly.
                //
                // We just need things to be deterministic here so just pick
                // something that isn't zero. This time, chosen after careful
                // deliberation, corresponds to Jul 23, 2006 -- the date of the
                // first commit for what would become Rust.
                self.set_mtime(1153704088);

I don't see why these should be different, and it causes an annoyance in one of our use-cases.

Is there a reason why these two dummy values should be different?

mkaput added a commit to software-mansion/scarb that referenced this issue Nov 13, 2023
Although the `set_metadata_in_mode` call should set `mtime` to a
deterministic value, it fails to do so due to
alexcrichton/tar-rs#341. Also, the constant
value used there is funky and I do not feel convinced about its
stability. Therefore, we use our own `mtime` value explicitly here.

Signed-off-by: Marek Kaput <marek.kaput@swmansion.com>
mkaput added a commit to software-mansion/scarb that referenced this issue Nov 13, 2023
Although the `set_metadata_in_mode` call should set `mtime` to a
deterministic value, it fails to do so due to
alexcrichton/tar-rs#341. Also, the constant
value used there is funky and I do not feel convinced about its
stability. Therefore, we use our own `mtime` value explicitly here.

fix #883

Signed-off-by: Marek Kaput <marek.kaput@swmansion.com>
github-merge-queue bot pushed a commit to software-mansion/scarb that referenced this issue Nov 13, 2023
Although the `set_metadata_in_mode` call should set `mtime` to a
deterministic value, it fails to do so due to
alexcrichton/tar-rs#341. Also, the constant
value used there is funky and I do not feel convinced about its
stability. Therefore, we use our own `mtime` value explicitly here.

fix #883

Signed-off-by: Marek Kaput <marek.kaput@swmansion.com>
alexcrichton pushed a commit that referenced this issue Jun 4, 2024
* Unify `mtime` constant used on Unix and Windows

fix #341

* Extract `DETERMINISTIC_TIMESTAMP`
ararslan pushed a commit to ararslan/binstall-tar that referenced this issue Jun 6, 2024
* Unify `mtime` constant used on Unix and Windows

fix alexcrichton#341

* Extract `DETERMINISTIC_TIMESTAMP`

(cherry picked from commit dd9123c)
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 a pull request may close this issue.

1 participant