php zip archive not working apache server hard disk full problems
Over the years of hosting up to 14 websites on different hosting companies I found two particular problems.
Flaws on Apache servers
I have discovered some problems regarding having the server hard disk full.
My hard disk was full and the contents occupied 19.41GB out of 20GB in my current server. I had 5 websites hosted on this account and many backup directories. As a PHP software developer, working on live websites, I do create a lot of backups. This is because if my latest upgrades to do not work properly I can delete it and rename the backed up copy to the original name within minutes.
In this case I had an account which had 5 websites, under /public_html/ in cPanel, and the hard disk space occupied was 19.41GB out of 20GB. I had tried to restore one of the websites and found that it did not restore properly as many files were missing. This was because I had exceeded the allowed disk space.
As a result I was not trying to restore or copy anymore files. All I did was to delete the contents of one of the websites to make available more disk space. After deleting I found all 5 websites deleted - everything in my account deleted. My /public_html/ directory was empty - 0 bytes. That is tragic, isn't it? It should have just deleted that one website's sub directories and not all 5 websites.
Why did the server delete the whole account
I decided to delete the contents of one of the subdirectories in one of the website directories as the hard disk was full. When I deleted the contents of one of the website directories the entire account was deleted. I lost all 5 of my websites.
I know I am not that knowledgeable about server software and that was the reason I was sounding out these problems to see if anyone else has experienced them and to know how they coped with them. Is it a bug? Is there an upgrade? I would suspect it is a bug or a design flaw in the software because the source files were emptied and all my websites were deleted. Unfortunately, I do not know where to report this problem.
Some thing is not right but the server people will have to look into it.
Previous hosting had similar problems
This is a serious issue and I have seen this problem in other hosting provider, Reseller Panel, when the hard disk is full. It does not happen when the hard disk has a lot of free space. Those tech support staff from a previous hosting company denied that there was a problem with their OS or Apache or their custom 'cPanel' or whatever. Now I find it occurring in another hosting company.
In previous case my server hard disk was not full but was occupying a lot of disk space. When I tried to copy a directory to a new named directory the operation failed and both my source files and destination files were emptied out and set to zero bytes. Something is seriously wrong if the source files are emptied out, right? I can understnd if it failed to copy to a destination file but emptying out the source files too. That looks supcious. Is it a bug or hacker corrupted OS?
This was very dangerous as the hosting provider had promised unlimited disk space. Unfortunately, what they did not tell any of us webmasters, is that if the backup function tried to backup more than 5GB it would fail. So there is a limit to disk space occupied and we were not given unlimited disk space.
Isn't that a fraudulent claim to advertise "unlimited disk space" and then limit how much can be backed up?
I want to highlight that there is a flaw somewhere in Apache or Linux or OS modifications that monitor disk space usage. I do not know where the flaw is. When the disk space is almost full the software runs into problems and begins deleting files and directories. To date the hosting providers are in denial of this problem.
PHP zip archive failure
I found that PHP script generated zip files cannot be restored if the compression was done using PHP 5.6 or higher, even with PHP 7.3. So far hosting providers have asked me to write my PHP scripts to compress in .tar.gz or other formats but that is not the answer. No one has fixed this.
I have reported this to the PHP bug forum but there has been no response. Please read https://bugs.php.net/bug.php?id=69536. I do not know whether there is a fix and the hosting companies just do not want to implement an upgrade or the world is moving away from zip compression to some other format that I am not aware of. Is the world moving away from zip compression?
PHP zip archieve was not written properly
I ran another test on the PHP zip archive issue. I found that, with PHP 5.5 all file permissions are set to 0644. It does not matter whether the original file permissions were set to 0666 or 0444 or any other value. When you unzip the file the the permissions will be set to 0644.
I then tested this with PHP 5.6 and tried to zip and unzip files whose permissions were 0644 or 0444. When unzipped their permissions where set to 0666.
Further testing showed that the file permissions were set at the point of compression and not during unzipping. As I unzipped a file under PHP 5.6, that was zipped under PHP 5.5, and it unzipped with file permission of 0644. When I unzipped a file under PHP 5.5 that was zipped under PHP 5.6 the file permission were set to 0666. It did not matter what the original permissions were.
This clearly shows that the PHP zip archive function does not check the file or directory permissions when zipping files. It just defaults them to 0644 or 0666. Why?
Why did the developers not check the file permissions for the files being compressed and use those values? fileperms()? Can't we specify what permission we want the directories and files to be? For example:-
$zipArchive->addFile('atestzip.php', 'atestzip.php', 0644);
$zipArchive->addEmptyDir ( string $dirname, 0755 );
There could be a way create default settings for directory and file permissions:-
$zipArchive->setpermissions ( 0755, 0644 );
By doing this, we can write a PHP script to check every file's permission and set the permission before adding it to be compressed. If the permission is not set then a default setting can be used.
- Dr. Peter Achutha, 16th February 2019