Strict and Rename errors installing CMSB 2.17

11 posts by 4 authors in: Forums > CMS Builder
Last Post: December 20, 2012   (RSS)

By garyhoffmann - September 25, 2012 - edited: September 25, 2012

Hi,
I’m in the process of taking my “standard installation” which is on CMSB 2.14 and trying to update it to 2.17.

To keep things really simple, I’m starting with a “vanilla” 2.17 installation. Ultimately, I have a lot of pre-defined schema files that are all based on 2.14 schema methodology that I’d like to bring forward, but I thought I’d start simple.

When I first upload all the files to the site and try to run the CMS Installer, I’m getting errors that I’ve never received before:

First, I’m getting a Strict warning regarding the timezone (windows server BTW) and then I’m getting a rename error – I believe what’s happening is the settings.dat.php.default is being successfully renamed to settings.data.php, but then it’s trying to update the settings to V2.17 “correct” values and fails renaming the temp file to settings.dat.php because the file already exists.

The attachment shows the file has been renamed and it fails while trying to rename a second time.

Strict Standards: rename(): It is not safe to rely on the system's timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected 'America/Chicago' for '-5.0/DST' instead in C:\Inetpub\vhosts\zslegal.com\httpdocs\cmsAdmin\lib\common.php on line 444 Warning: rename(C:/Inetpub/vhosts/zslegal.com/httpdocs/cmsAdmin/data/settings.dat.php.50626b78c549b2.77836685-temp.php,C:/Inetpub/vhosts/zslegal.com/httpdocs/cmsAdmin/data/settings.dat.php): File exists in C:\Inetpub\vhosts\zslegal.com\httpdocs\cmsAdmin\lib\common.php on line 444 Error renaming over C:/Inetpub/vhosts/zslegal.com/httpdocs/cmsAdmin/data/settings.dat.php: rename(C:/Inetpub/vhosts/zslegal.com/httpdocs/cmsAdmin/data/settings.dat.php.50626b78c549b2.77836685-temp.php,C:/Inetpub/vhosts/zslegal.com/httpdocs/cmsAdmin/data/settings.dat.php): File exists

I do not have these problems in CMSB 2.14 nor have I ever had this type of problem going all the way back to V1.3*, so it's something that has changed very recently.
Attachments:

9-25-2012-9-43-13-pm.png 30K

Re: [garyhoffmann] Strict and Rename errors installing CMSB 2.17

By garyhoffmann - September 25, 2012 - edited: September 25, 2012

I might have a resolution to it....

I changed the saveStruct routine to use rename_winsafe and then updated rename_winsafe to not die and to simply to the copy/unlink if the rename was unsuccessful and that got us past the problem. I don't know how many other places there will be a similar problem but wanted to pass on what I did and what I found.

I have 2.17 in a test area right now and plan to setup a test database with it as time permits, but I'm definitely behind schedule on a few projects, so don't know how much time I'll have to spend on it over the next several days.

However, I did get the chance to do a quick search of the rename function and there are not that many places within cmsAdmin that use the rename function:


C:\Downloads\CMS Builder\cmsBuilder217-windows\RootAddins\cmsAdmin>findstr /isc:"rename(" *.php
3rdParty\tiny_mce\plugins\spellchecker\classes\utils\Logger.php:
@rename($rfile, $nfile);
3rdParty\tiny_mce\plugins\spellchecker\classes\utils\Logger.php: @rename($log
File, $this->toOSPath($logFile . ".1"));
lib\common.php:// On windows PHP < 5.2.9 copy fails if the destination file exists so this function
tries a rename() then tries copy and unlink if rename fails
lib\common.php: // try rename() as-is first
lib\common.php: $r1 = @rename($oldfile,$newfile);
lib\common.php: if (!rename($tempFilepath, $filepath)) {
lib\common.php: @rename($defaultFile, $targetFile) || die("Error renaming '$defaultFile'!<br/
>Make sure this file and it's parent directory are writable!");
lib\menus\database\editTable_functions.php: rename($oldSchemaFilepath, $newSchemaFilepath) or die
("Error renaming schema file!");
lib\upload_functions.php: rename($uploadInfo['tmp_name'], $saveAsFilepath) || die("Error moving u
ploaded file! $php_errormsg");

C:\Downloads\CMS Builder\cmsBuilder217-windows\RootAddins\cmsAdmin>

Re: [garyhoffmann] Strict and Rename errors installing CMSB 2.17

By Dave - September 26, 2012

Hi Gary,

Thanks for the report.

I just came across this same issue myself, that on windows rename() doesn't overwrite files in PHP < 5.3.

I've updated the code for the next release to use rename_winsafe (and optimized/tested that function).

It only uses the rename() overwrite functionality in common.php, so the quick fix is just to replace rename with rename_winsafe, or alternatively just upgrade PHP to 5.3 or better.

Also, note that for the next release of CMSB we're going to be upping the server requirements to PHP 5.2.4+ and MySQL 5.0+, so if you're running lower version then those it might be a good time to upgrade as well.

Hope that helps, let me know any questions.
Dave Edis - Senior Developer
interactivetools.com

Re: [Dave] Strict and Rename errors installing CMSB 2.17

By ITI - November 28, 2012

Hi Dave

I've updated the code for the next release to use rename_winsafe (and optimized/tested that function).

It only uses the rename() overwrite functionality in common.php, so the quick fix is just to replace rename with rename_winsafe, or alternatively just upgrade PHP to 5.3 or better.

Also, note that for the next release of CMSB we're going to be upping the server requirements to PHP 5.2.4+ and MySQL 5.0+, so if you're running lower version then those it might be a good time to upgrade as well.



I also ran into this issue trying to do a fresh install.
Regarding your next release and the minimum requirements.
I currently use PHP 5.2.17

Replacing "rename" with "rename_winsafe" still produces an error:
"rename_winsafe: This is a dev function not ready for use."

That said your min requirement of PHP 5.2.4 may not be enough.

I got around this issue with this modification:
if (!@rename($tempFilepath, $filepath)) { // added @ to suppress the error
if(!copy($tempFilepath,$filepath)){
die("Error copying $tempFilepath to $filepath: $php_errormsg");
}
unlink($tempFilepath);

};


Maybe this will help others with a slightly out-of-date version of php.
Glen







http://www.CanadianDomainRegistry.ca







ITI Internetworking Technologies Inc.

Re: [ITI] Strict and Rename errors installing CMSB 2.17

By Dave - November 28, 2012

Hi Glen,

Thanks for the post. I can send you a beta of 2.50 as well if you'd like to try that. PHP 5.2.17 is newer than 5.2.4 so you should be fine. I'll email you direct. Thanks
Dave Edis - Senior Developer
interactivetools.com

Re: [Dave] Strict and Rename errors installing CMSB 2.17

By ITI - November 28, 2012

Thanks Dave

I'm already on your list for beta testers and have the link to download 2.50 so there is no need to email it to me.

I will have a look when I have a bit more time.
Glen







http://www.CanadianDomainRegistry.ca







ITI Internetworking Technologies Inc.

Re: [ITI] Strict and Rename errors installing CMSB 2.17

By Dave - November 28, 2012

No worries. I just emailed you a zip of the latest beta with your suggested www. settings file fix and a rename_winsafe fix. Let me know any feedback (over email).

Thanks!
Dave Edis - Senior Developer
interactivetools.com

Re: [ITI] Strict and Rename errors installing CMSB 2.17

Hello,

I am trying to install cmsBuilder 2.50 on centOS 6 and I am receiving the following error, which seems to be related to this thread:

rename_winsafe: rename return value not boolean true or false!

Could someone please give me a hand resolving this?

Thank you,

Greg

Re: [ITI] Strict and Rename errors installing CMSB 2.17

Hi Dave,

My hosting company actually helped fix this for me. They told me to run the following command on my server, which then allowed me to run the installation wizard:

chown -R apache.apache /var/www/html/cmsAdmin

I am not sure what that does but it certainly fixed the problem!


Thanks,

Greg