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.

Sign up for GitHub

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

Jump to bottom

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

Open
abizjak opened this issue Oct 26, 2023 · 0 comments · May be fixed by #346
Open

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

abizjak opened this issue Oct 26, 2023 · 0 comments · May be 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 mkaput mentioned this issue Nov 13, 2023
Closed
mkaput added a commit to software-mansion/scarb that referenced this issue Nov 13, 2023
@mkaput
Use constant mtime for packaged tarballs
5be5a7e 
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
@mkaput
Use constant mtime for packaged tarballs
843d15a 
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>
@mkaput mkaput mentioned this issue Nov 13, 2023
Merged
mkaput added a commit to mkaput/tar-rs that referenced this issue Nov 13, 2023
@mkaput
Unify mtime constant used on Unix and Windows
7bd8318 
fix alexcrichton#341
@mkaput mkaput linked a pull request Nov 13, 2023 that will close this issue
Open
github-merge-queue bot pushed a commit to software-mansion/scarb that referenced this issue Nov 13, 2023
@mkaput
Use constant mtime for packaged tarballs (#898)
4a0a6cf 
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Unify mtime constant used on Unix and Windows mkaput/tar-rs
1 participant
@abizjak