I don't think we're doing anything explicitly to cause this. Do you have achmodWritableValue
set in config.php?
Just to clarify, which particular files are you talking about?
What is your PHP setup? More specifically, what user owns the files? What user does PHP run as?
_build
directory aren't writable, so it seems that it could be something your zip system is doing.Well, the Zip system ultimately just uses ZipArchive behind the scenes so I'm not sure what it could be doing differently.
Can you perhaps try to be a bit clearer about exactly what you're doing to ascertain that the files contained within the Zip are world writable? Are you doing anything (like zipinfo or a specific archive GUI) to inspect the contents of the Zip file in place, for example?
We'll then be able to take a closer look.
unzip -Z
also shows the permissions of the files inside (on both my Mac and my external server).unzip -Z
, I do see permissions:unzip -Z
.unzip -Z
, the permissions look standard. // Begin the zip
$zip = new ZipArchive();
if (($result = $zip->open($filepath, ZIPARCHIVE::CREATE | ZIPARCHIVE::OVERWRITE)) !== true)
{
// Couldn't open the zip
throw new Exception($vbphrase['dbtech_vbecommerce_invalid_temp_dir']);
}
foreach (VBECOMMERCE_FILE::$map as $filename => $shortfile)
{
// Grab the extension
$ext = strtolower(VBECOMMERCE_FILE::fetch_extension($filename));
switch ($ext)
{
case 'png':
case 'gif':
case 'jpeg':
case 'jpg':
case 'psd':
case 'ttf':
case 'zip':
case 'ogg':
$zip->addFile($filename, $addOnDir);
break;
default:
// Various replacements on the file contents go here
$zip->addFromString($addOnDir, $file);
break;
}
// Finally close the zip
$zip->close();
unzip
and macOS' default zip extractor too, so I switched to The Unarchiver which does not suffer from this problem.setExternalAttributesName
method and this can be used to give us the desired effect, see http://php.net/manual/en/ziparchive.setexternalattributesname.php.We use essential cookies to make this site work, and optional cookies to enhance your experience.