Jump to content

Corrupted version after development


Recommended Posts


i've just continued on my app today and i have issues deploying it:
Screen Shot 2016-12-24 at 12.52.17 1.png

It is not the directory permission. This one is set to 777 on the application directory:
Screen Shot 2016-12-24 at 12.55.43.png

So it appears it is the first issue.

Does anyone has experienced such an issue so far? What could be done for resolving it?
My whole source code including the latest version is here:

Thanks for the help and merry christmas.



Edit: It is worser than expected. Somehow the application was partially installed. Some hooks are there from the new application. Which is painful since it destroied my suite. When an application failed to upgrade all things should be reverted, shouldn't it? Isn't it in some kind an architecture failure?

Link to comment
Share on other sites

Next time you have an issue try searching for the code error in the files first, in your case above this is what triggers it:

				if ( mb_substr( $values['application_file'], -4 ) !== '.tar' )
					/* If rename fails on a significant number of customer's servers, we might have to consider using
						move_uploaded_file into uploads and rename in there */
					rename( $values['application_file'], $values['application_file'] . ".tar" );
					$values['application_file'] .= ".tar";
				/* Test the phar */
				$application = new \PharData( $values['application_file'], 0, NULL, \Phar::TAR );
 				/* Get app directory */
				$appdata		= json_decode( file_get_contents( "phar://" . $values['application_file'] . '/data/application.json' ), TRUE );
				$appDirectory	= $appdata['app_directory'];
				/* Extract */
				$application->extractTo( \IPS\ROOT_PATH . "/applications/" . $appDirectory, NULL, TRUE );
				$this->_checkChmod( \IPS\ROOT_PATH . '/applications/' . $appDirectory );
			catch( \PharException $e )
				\IPS\Output::i()->error( 'application_notvalid', '1C133/9', 403, '' );


As you can see above it catches a Phar extension exception trying to extract the files, that's why it is saying your application is not valid. Double-check phar is available on your PHP installation.

Link to comment
Share on other sites


yea you are right, i could have checked that. However, it is still not working. I'me using PHP7 where Phar is no longer an extension, by having the 'common' package included it is installed.
I have checked additionally the php.ini file for apache:

; http://php.net/phar.readonly
;phar.readonly = On

; http://php.net/phar.require-hash
;phar.require_hash = On

;phar.cache_list =

It is also not in read only mode.
The weird thing is, it worked always. Just suddenly stopped without touching anything.

I have also recheck the permissions, which are totally fine...


Link to comment
Share on other sites

  • 2 weeks later...
On 28.12.2016 at 4:29 PM, bfarber said:

You can try adding


Inside the exception catch pointed out above to see what is being reported by PHP.

Thanks for the tip.

I have decided to recreate the application and copy the whole code, which is obviously a pain in the ass :D 
But it is working now again as expected.

Link to comment
Share on other sites

The issue appeared again on my new application after i made an upgrade today. It's getting strongly annoying developing under IPS....

I got the error output now:

object(PharException)#150 (7) { ["message":protected]=> string(172) "Extraction from phar "/tmp/phpvO0SJf.tar" failed: Cannot extract "hooks/data.php" to "/var/www/ips_f398e/applications/stats/hooks/data.php", setting file permissions failed" ["string":"Exception":private]=> string(0) "" ["code":protected]=> int(0) ["file":protected]=> string(80) "/var/www/ips_f398e/applications/core/modules/admin/applications/applications.php" 

Which is total bullfaeces, the folder has full read/write permissions. I assume the compile of the file is somehow broken and corrupted. The compile generally takes me 4-5 minutes. Maybe the apache timeout is causing an issue there. It was once around 5 minutes and the last compile was done after 4 minutes, which does speak against apache timeout.

Link to comment
Share on other sites

That specific error isn't really specific to our software FWIW. PHP handles phars itself - it sounds like when it tries to extract the one file, setting permissions on the file afterwards fails. This could be because the file (data.php) from the source or destination installation has permissions (or file ownership) set improperly, perhaps.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...