fix: set mtimes to extraction time after extracting Electron zips - #1940
Draft
claude[bot] wants to merge 1 commit into
Draft
fix: set mtimes to extraction time after extracting Electron zips#1940claude[bot] wants to merge 1 commit into
claude[bot] wants to merge 1 commit into
Conversation
Electron's dist zips have every entry's timestamp zeroed to the DOS epoch (1980-01-01). The Rust-based extractor used since v20.0.1 faithfully restores archive mtimes, so packaged apps ended up with every file dated 1980. Reset timestamps to the extraction time after extracting, matching the observable behavior of packager 18 and earlier, and preserve timestamps in the EXDEV copy fallbacks so both staging paths behave like rename.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Requested by Erick Zhao, Samuel Attard · Slack thread
unzip.spec.tstest, build, and lint pass locally; suites requiring Electron binary downloads could not run in the sandboxed environment used to prepare this PR.)Summarize your changes:
Before: Apps packaged with
@electron/packager>= 20.0.1 (and Forge 8.0.0-alpha.9+) have every file dated 1980-01-01, visible in Explorer and breaking installer/updater/backup expectations. Electron's dist zips zero-date every entry to the DOS epoch, and the Rust-based@electron-internal/extract-zipfaithfully restores archive mtimes — unlike the old JSextract-zip, which ignored them and left files stamped with the extraction time.After: Extracted files get the packaging time, matching packager 18 and every earlier release. The extractor itself is unchanged — per maintainer discussion, restoring archive mtimes is its correct behavior, so the normalization belongs in packager.
How: After
extract()completes inextractElectronZip(src/unzip.ts) — the single choke point all packaging flows go through — a small sequential walker (fs.promises.readdirwithwithFileTypes) recursively sets atime/mtime of every extracted file and directory to the current time, usinglutimesfor symlinks so link targets aren't touched. Additionally, the twofs.cpEXDEV fallbacks insrc/platform.tsnow passpreserveTimestamps: true, so cross-device staging behaves the same as therenamefast path. That asymmetry is why the bug appeared Windows-only: same-volumerename(typical on Windows) preserved the 1980 mtimes, while cross-devicecp(typical on Linux, temp dir on a different mount) reset them as a side effect.The new test extracts a committed fixture zip whose entries are DOS-epoch-dated and asserts the extracted files' mtimes are recent; it fails against the previous
unzip.ts(files dated exactly1980-01-01T00:00:00Z) and passes with this change.Affected versions:
@electron/packager>= 20.0.1 and Forge 8.0.0-alpha.9+.Fixes #1939
Generated by Claude Code