Repository navigation
PharData archive created with Phar::Zip format does not keep files metadata (datetime) #10766
Description
Description
Having a file created this day (2023-03-03) named myfile.txt in /tmp directory.
The following code:
<?php
$a = new \PharData('/tmp/archive.zip', \FilesystemIterator::SKIP_DOTS | \FilesystemIterator::UNIX_PATHS, null, \Phar::ZIP);
$a->addFile('/tmp/myfile.txt', 'name');
$b = new \PharData('/tmp/archive.tar', \FilesystemIterator::SKIP_DOTS | \FilesystemIterator::UNIX_PATHS, null, \Phar::TAR);
$b->addFile('/tmp/myfile.txt', 'name');Resulted in this output (uncompress '/tmp/archive.zip' archive):
name 1980-01-01
But I expected this output instead (uncompress '/tmp/archive.tar' archive):
name 2023-03-03
PHP Version
PHP 8.2.0
Operating System
MacOS 13.2
Activity
franck-paul commentedon Mar 3, 2023
This issue is also valid for PHP 7.4, PHP 8.0 and PHP 8.1
ndossche commentedon Mar 3, 2023
I can confirm this on 8.1+ and I'll now try to debug this issue.
Fix phpGH-10766: PharData archive created with Phar::Zip format does …
Fix GH-10766: PharData archive created with Phar::Zip format does not…
Merge branch 'PHP-8.1' into PHP-8.2
Merge branch 'PHP-8.2'
franck-paul commentedon Mar 17, 2023
I see that PHP 8.2.4 and 8.1.17 have been released but without any fix about this issue, do you why?
PharData zip metadata bug still not fixed with 8.2.4 and 8.1.17 (see p…
ndossche commentedon Mar 17, 2023
The fix is applied to those versions.
Does the original code in your opening post still reproduce the issue for you? I just tried your code from the opening post and it works on my machine.
franck-paul commentedon Mar 17, 2023
Oh ok, I have not test it yet, but seeing the 8.2.4 and 8.1.17 branches on this very repository does not show any modification in file
ext\phar\zip.cit's why I asked this.php-src/ext/phar/zip.c
Line 150 in 494d9e1
php-src/ext/phar/zip.c
Line 150 in 40a1a86
And your modification is:
php-src/ext/phar/zip.c
Line 151 in 31ccfbd
ndossche commentedon Mar 17, 2023
@franck-paul Sorry I just realised something, I was testing on the latest 8.1 development build...
The fix is indeed not in 8.1.17 and 8.2.4, because the fix was created when the development cycle of those versions were already ended. So the fix will be available in the next release of 8.1 and 8.2.
franck-paul commentedon Mar 17, 2023
You're welcome and thanks for confirming!
danepowell commentedon Oct 27, 2023
I suspect that fixing this revealed a deeper bug in the timezone handling: #12532