Downloaded packages have incorrect file modification timestamps

[thomasfw]

Downloaded packages have incorrect file modification timestamps

[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 composer/composer#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 🤷

[thomasfw]

Great, thanks 🙂