Downloaded packages have incorrect file modification timestamps

[thomasfw]

Describe the bug

When downloading mirrored package releases from our satis repo, the resulting unzipped files have a modified time of Tuesday, 1 January 1980 at 00:00.

This is causing a bit of a headache for us, specifically where our packages are providing Blade template files. The Blade engine fails to pick up template changes because the file modification times are incorrect.

I've also manually downloaded a few different releases from satis and confirmed that the modified times are incorrect. So I don't think this is something Composer is doing on the production server, or something specific to those environments.

When I download a release directly from GitHub, the file modification time is set to the time of the tagged release as it should be.

To Reproduce

🤷‍♂️ ... maybe somebody can download a mirrored package release (ideally with GitHub as the source) from their satis repo and check the file modification times match the release's date?

Outcome

N/A

Expected behavior

The file modification times should be set to the time of the tagged release. I also realise that the cause of this might not be satis but this is the first port of call.

Additional context

We've been using our satis repo for a few years and haven't run into this issue up until now. We did recently switch all of our private repos from BitBucket to Github, and updated the packages in our satis.json to use the new sources.

[thomasfw]

I've been digging into this a bit more... I see that there's an undocumented (or at least it isn't mentioned in the official docs) archive.rearchive option which is enabled by default.

Having disabled this, ~98% of the zip archives now contain the correct timestamps.

The other ~2% of the archived releases still contain incorrect timestamps for some inexplicable reason. I can only assume this is something to do with the package's dist type causing the archive.rearchive config option to be overridden. Once unzipped, the archives with the incorrect timestamps spit out a directory with a different naming convention to the (non re-archived) ones with correct timestamps, which also suggests to me that they are indeed being re-archived and that this is the cause of the issue.

Are there any cases where a package dist type might not be tar or zip, thus forcing the re-archiving?

What is the reason for re-archiving anyway? I see that satis is using Composer\Package\Archiver\ArchiveManager::archive() for this. In which case it looks like I need to open an issue up there, so that the timestamps are preserved.

Thoughts on this from satis maintainers would be much appreciated.

[thomasfw]

@alcohol Hi, it would appear that there are issues setting mtime on files archived using ZipArchive in php <8. Do you have any ideas for how this could be fixed in Satis?

Considering the outcome of the discussion in https://github.com/composer/composer/issues/11342, it seems to me that bumping Satis' minimum php version to 8 and also checking for the ext-zip extension might be the best (and least time consuming) solution.

{
    "require": {
        "php": "^8.0",
        "ext-zip": "*"
    }
}

[alcohol]

Done via bab7ca3. The container release artifact of satis includes said necessary extensions. Git clone users might be less happy about this implementation, but c'est la vie :shrug:

[thomasfw]

Great, thanks 🙂