Corrupted version after development

[GriefCode]

Hey, 

i've just continued on my app today and i have issues deploying it:

It is not the directory permission. This one is set to 777 on the application directory:

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:
https://github.com/gamershost/Forum-Application

Thanks for the help and merry christmas.

Greetings

 

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?

[teraßyte]

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:

			try
			{
				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 );
				\IPS\IPS::resyncIPSCloud();
			}
			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.

[GriefCode]

Hey,

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:
 

[Phar]
; 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...

Regards

[bfarber]

You can try adding

var_dump($e);exit;

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

[GriefCode]

On 28.12.2016 at 4:29 PM, bfarber said:

You can try adding

var_dump($e);exit;

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  
But it is working now again as expected.

[GriefCode]

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.

[GriefCode]

So, i now manually upgraded by copying files and then use the /admin/upgrade which worked for me...

[bfarber]

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.