rename operation "not permitted" in smarty's "core.write_file.php" ...
| Project: | Bluemarine_smarty |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
hi,
i've installed:
drupal 4.7b2 on osx 10.4.3
apache 2.3.0-dev / worker mpm
php 5.1.1
smarty v2.6.11
i've installed the SmartyThemeEngine for drupal 4.7, and DL'd & activated bluemarine_smarty theme.
with this theme active, it seems at first glance to be mostly 'there', but i currently see a warning 'box' w/:
warning: rename(/var/tmp/wrt1lFc00,themes/engines/smarty/templates_c/bluemarine_smarty/%%76^768^768A43D8%%block.tpl.php) [function.rename]: Operation not permitted in /Library/WebServer/tools/smarty/libs/internals/core.write_file.php on line 46.
where, in core.write_file.php
45: }
46: @rename($_tmp_file, $params['filename']);
47: @chmod($params['filename'], $smarty->_file_perms);
with my other smarty-based apps, no such issues that i've noticed.
this 'smells' like perms, but, fwiw, all my files in/below /Library/WebServer are chmod www:www ...
search on core>write_file.php yields, alas, nada. :-/
richard
#1
I dont have 5.1 in my testing environment but I somewhat doubt this is the issue.
I smell permissions as well.
The templates_c folder and subdirectories definitely have the user-write bit set?
run a quick 'sudo rm -r templates_c/*' and then make sure it's chmodded appropriately. (unsure of minimum required, 600 is likely enough but do a 755 for testing).
Please post again.
#2
I'm no mac user -- am I right in assuming apache runs as the 'www' user?
chmod it 777 and report back.
#3
hi travis,
i just used "www" to indicate that i *have* verified that it is the user/group that apache runs as , and the users/perms on my dirs/files.
i use my own builds, setup to my specs/reqts, and use a dedicated user/group i create (actually, in current case, not www, but the idea holds ...)
as for what apple's 'default" is for apache, i have no clue .... probably www ... but dunno, and if i understand your question, it doesn't matter here.
cheers,
richard
#4
as for the templates_c dir, perms look OK:
% cd .../sites/drupal/themes/engines/smarty
% ls -al templates_c/bluemarine_smarty/
total 8
-rw-r--r-- 1 www www 457 Jan 7 16:18 %%76^768^768A43D8%%block.tpl.php
-rw-r--r-- 1 www www 3156 Jan 7 16:18 %%D8^D8B^D8BE8273%%page.tpl.php
drwxr-xr-x 4 www www 136 Jan 7 16:18 .
drwxrwxr-x 5 www www 170 Jan 7 16:18 ..
note that dir is already mod 755 ...
richard
#5
for experiment, i just:
chmod -R 777 .../sites/drupal/themes/engines/smarty/templates_c/
chmod -R 777 .../sites/drupal/themes/bluemarine_smarty/
and retried.
no change, same error.
#6
hi travis,
>> I can't reproduce this (on linux, php4.4.0)
>> I think it's permissions.
> Can you run a manual test fwrite()ing to the templates_c directory?
assuming you're just querying directory writeability ... quick-n-dirty should do it:
======================================================
${EDITOR} .../sites/drupal/sites/drupal.testdomain.com/test.php
<?phpglobal $smarty;
$fp = fopen("/.../sites/drupal/themes/engines/smarty/templates_c/test.txt",'w');
fwrite($fp,print_r($smarty, true));
fclose($fp);
?>
======================================================
% ls -al .../sites/drupal/themes/engines/smarty/templates_c/test.txt
/usr/local/bin/ls: .../sites/drupal/themes/engines/smarty/templates_c/test.txt: No such file or directory
% cd .../sites/drupal/sites/drupal.testdomain.com/
% php -i
phpinfo()
PHP Version => 5.1.1
System => Darwin devuser 8.3.0 Darwin Kernel Version 8.3.0: Mon Oct 3 20:04:04 PDT 2005; root:xnu-792.6.22.obj~2/RELEASE_PPC Power Macintosh
Build Date => Jan 6 2006 23:17:13
...
% php test.php
% ls -al .../sites/drupal/themes/engines/smarty/templates_c/test.txt
-rw-r--r-- 1 root www 0 Jan 9 10:56 .../sites/drupal/themes/engines/smarty/templates_c/test.txt
i note you're using php 4x ... is this, perhaps, a php5x issue? wouldn't be unheard of, eh? unfortunately, i have no 4x instance handy ....
richard
#7
This was determined to be a caching issue but may turn into a more complex issue.
Marking as fixed -- clear the cache if you have initial permission problems.
#8