I am trying to open a ZIP file using PHP 5.6.24 on Windows Server 2008. As it is running XAMPP, Apache and PHP are 32bit.
The file in question is 2.5 GB and cannot be opened, ZipArchive::open() returns the error code 19 (Not a zip archive). However, the file checks out okay. Using the same method on Linux (64bit) with the same PHP version, there is no error on the same file.
I have removed entries from the Zip file to reduce the file size to 1.9 GB, and PHP has no issues processing that file.
The code is simple:
$za = new ZipArchive();
$err = $za->open('file.zip');
The only thing I can imagine is that for some reason, 32bit PHP cannot cope with archives > 2GB, but I have not found anything on this. I found mentioning of a 4 GB limit and of 64k files, but that doesn't apply in this case.
Is there anything I can do, maybe a configuration option, to be able to process this file?
Related
Is this a bug with how the finfo->buffer method works? I noticed that PHP allocates a significant amount of memory when determining mime type using finfo, and only with certain file types like csv and txt files. Quick sample code below:
// Load a 60 MB CSV file
$contents = file_get_contents('file.csv');
$finfo = new finfo(FILEINFO_MIME_TYPE);
// Outputs text/plain. Peak memory usage after this is 400+ MB
echo $finfo->buffer($contents);
If I try a different file type though, like a large zipped archive for example, memory usage barely changes after the file_get_contents call.
This was tested on PHP 7.2.28
it can be some sort of php or libmagic bug as mentioned here:
https://bugs.php.net/bug.php?id=79263
https://bugs.php.net/bug.php?id=78987
I saw the Issue on a machine with:
php 7.3.31-1~deb10u1
libmagic 533
but there wasn't any problem on another machine with this config:
php 7.4.29
libmagic 537
so if you update your software packages the problem should be fixed.
another work around would be using file() method.
instead of:
$finfo->buffer($contents);
saving the content somewhere on the disk, then :
$finfo->file($filepath);
links:
libmagic file Issue, on version 5.33
its been 3 days of research, google and frustration to make imagick work on my XAMPP box. I can get as far on making it as php module. But it cannot detect supported formats.
As you can see, I currently have 3.1.2 installed, but I actually worked all the way from the most recent 3.4.1 and jumping from those releases tagged with stable but I just can't make it work.
When I try to run:
<?php
$handle = fopen('http://xxxxx.png', 'rb');
$img = new Imagick();
$img->readImageFile($handle);
$img->thumbnailImage(100, 0);
echo $image;
I am getting:
Uncaught exception 'ImagickException' with message 'Unable to read image from the filehandle' in xxxxx:5 Stack trace: #0 xxxxx\index.php(5): Imagick->readimagefile(Resource id #3) #1 {main} thrown in xxxxx\index.php on line 5
What I have is:
Windows 8.1 64-bit
PHP 5.6.12, x86, TS
(http://i.imgur.com/2pnneqO.png)
This is what I actually have done so far, in terms of installing it:
Download any -Thread Safe (TS) x86 package from
https://pecl.php.net/package/imagick
Extract the .zip (1) php_imagick.dll to C:\_XAMPP\php\ext (2)
Extract CORE_RL_* files to C:\_xampp\apache\bin
Download ImageMagick-7.0.1-1-Q16-x86-dll.exe from
Link
Installed it at C:\ImageMagick
Add MAGICK_HOME to environment PATH. http://i.imgur.com/jQAWl3W.png
All *_.dll file in C:\ImageMagick\modules\coders copy to
C:\_Xampp\apache\bin
All *_.dll file in C:\ImageMagick\modules\coders copy to
C:\ImageMagick\
Restart Apache via Xampp
And still can't make my PHP detect Imagick supported file formats even though they should be http://prntscr.com/b1l54u :((
Can somebody tell me what did I miss? Please?
You seem to be going a bit of a convoluted route.
The method I used to install it when I had it running was:
Download and install Ghostscript with an exe file
Download and install imagemagick with an exe file - make sure you let it add the path to the environmental variables. You may not need this step but I wanted to use Imagemagick I'm my website and on my computer anyway.
Download the Imagick dll file and put it in the recommended folder - I can not remember which now.
Uncomment the Imagick option in the php.ini file. I had
two or three php.ini files on my system and I did it in each one.
Turned off the computer and restarted. Started XAMPP and it worked.
This only worked for a couple of installs and when I upgraded the operating system I could not get it to work due to incompatible versions of php and the Imagick.dll. If I should ever want to use Imagick I would do it on my server as the hosts installed it there for me.
You can still write your code locally and test it on your production server. It is a bit of a pain but would probably be quicker/easier than trying to get Imagick working on your PC.
Out of interest I gave up with it and use Imagemagick with exec() and the command line.
I am working on a script that uses the extractTo method of ZipArchive to unzip some pretty large files (some are over 10G). Everything works fine for small files, but I have been testing it with files that are ~4G and noticed that unzip works up to a point, then it stops actually unzipping. However, the PHP script appears to be running. No errors or exceptions are thrown. From a terminal I sit in the folder and keep typing ls -la to watch the size of the extracted file grow. It does so for a while, then stops and the script continues to load (watching via browser and via top). The script will then run for the specified timeout period (I set to 3600) and throw a time-out error. The box is running Centos 6.6, 16G of RAM, plenty of processing power, and plenty of disc space. Seems to be crashing at 5011800064 bytes unzipped. Here are some select bits of my code:
set_time_limit(1200);
ini_set('memory_limit', '1024M');
$zip = new ZipArchive;
$res = $zip->open($zipPath);
if ($res === TRUE)
{
$extres = $zip->extractTo(
$unzipPath,
$filesToExtract
);
$zip->close();
}
Any help would be greatly appreciated. I am also curious to know if the extractTo() function tries to load the whole zip into memory? I have scoured the PHP documentation and cannot find anything relevant. All of the related posts either do not have answers and were not specific in their explanation of the problem.
Edit: Just to confirm, I have over 20G free and setting different memory limits for the script doesn't change the number of bytes unzipped.
Update: I have scoured httpd.conf, php.ini, and cannot find any settings that are prohibiting the unzip operations from working.
A traditional .zip archive is limited in size to 4GB:
The maximum size for both the archive file and the individual files inside it is 4,294,967,295 bytes (232−1 bytes, or 4 GiB minus 1 byte) for standard .ZIP, and 18,446,744,073,709,551,615 bytes (264−1 bytes, or 16 EiB minus 1 byte) for ZIP64.
To decompress larger archives using ZIP64 in PHP, you'll need to use PHP 5.6 that uses libzip 0.11.2.
I want to zip a large folder of 50K files on Windows Server. I'm currently using this code:
include_once("CreateZipFile.inc.php");
$createZipFile=new CreateZipFile;
$directoryToZip="repository";
$outputDir=".";
$zipName="CreateZipFileWithPHP.zip";
define("ZIP_DIR",1); //
if(ZIP_DIR)
{
//Code toZip a directory and all its files/subdirectories
$createZipFile->zipDirectory($directoryToZip,$outputDir);
}else
{
//?
}
$fd=fopen($zipName, "wb");
$out=fwrite($fd,$createZipFile->getZippedfile());
fclose($fd);
$createZipFile->forceDownload($zipName);
#unlink($zipName);
Everything works fine until around 2K image files. But this is not what I want to get. I'm willing to process to zip like 50K images at least. Meanwhile my script gets this error:
Fatal error: Maximum execution time of 360 seconds exceeded in C:\xampp\htdocs\filemanager\CreateZipFile.inc.php on line 92
$newOffset = strlen(implode("", $this->compressedData));
I'm searching for any solution to proceed such a huge amount of files. I currently use XAMPP on Windows Server 2008 Standard. Is there any possibility to make small parts of the zips, use a system command and maybe external tool to pack them and then send it to header to download?
http://pastebin.com/iHfT6x69 for CreateZipFile.inc.php
try this .. to increase execution time
ini_set('max_execution_time', 500);
500 is number os seconds change it to whatever you lilke
Do you need a smaller file or a fast served file?
for fast serving without compression and without memory leak you could try to use the system command with a zip software like gzip and turning the compression of.
the files would probably get huge but would be served fast as one file.
I am trying to generate ioncube license using "make_license" generator provided by ioncube for Unix systems. It works on my desktop Ubuntu system, but does not work on my CentOS webserver.
Each time I try to run the file, I get message "Killed" in terminal, so it looks like this:
[root#myserver test]# ./make_license --passphrase 'secret' --expire-in 20d > 'license.txt'
Killed
[root#myserver test]#
Just a weird message "Killed" after I execute the file and nothing else. I also tried placing "sudo" in front of "./make_license --passphrase ....." and it worked, but license file was generated empty (0 bytes).
I have tried chmod 755 and 777 to "make_license", and it didnt help. Also I tried stopping "/etc/init.d/amavisd", just in case it's antivirus, but same thing.
My server configuration is: CentOS-6.2 64bit + Nginx, PHP-FPM, APC, php-ioncube-loader-4.2.2-2.el6.art.x86_64
I found the same question on Ioncube forum without answer:
http://forum.ioncube.com/viewtopic.php?t=3909&sid=8d595f7005f5b851479a00d387635ad7
Please share any ideas you might have.
So I contacted the ioncube support and this is what they replied:
There are two things to check here:-
That you have uploaded the make_license program to your server in binary mode and not in ASCII mode.
You have the 32-bit compatibility libraries installed (as make_license, like the Encoder, is a 32-bit program).
The loader does not matter in this case as it has nothing to do with
the problem with make_license.
You may need to install the 32-bit compatibility libraries for
CentOS for make_license to work as that is a 32-bit program.
The make_license file will be a binary in any case but if you uploaded
to your server via FTP in ASCII mode rather than binary then that
might corrupt the file and cause the "killed" message. So please
upload make_license again, making sure to choose binary mode in your
FTP client.
So I checked my make_license file:
[root#localhost test]# file make_license
make_license: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped
It says that file is "executable", which I thought is = "binary".
But apparently it wasn't binary. Because after I uploaded it again, making sure that transfer mode was "binary" in my FTP client - everything worked. No more "Killed" message and licenses are generated.
Hope this helps someone.