longmanさま

度々ありがとうございます。
chmod()のテストファイルをphpで作成し、該当ディレクトリ内で、テストしたところ、

phpファイル⇒そんなファイルはありません、といわれ、変更されない
ディレクトリ⇒775への変更を指示したのに、なぜか、パーミションは、407に変わる


seasoftさま
SSHでアクセスし、umaskを確認したところ、ディレクトリ内では、22が戻り値でした。


ちなみに、テストのコードは、間違っていないとは思うのですが、、、

一応該当ディレクトリ内に、test.phpという名称のファイルを作成し、下記コードを記載しました。また、ディレクトリ内に、「page.php」というファイルと「test」というディレクトリを作成しました。

<?php
$dir = 'test';
chmod($dir , 775 );
$file = 'page.php';
chmod($file , 664 );
?>

う、う〜ん。。。
ナゾが深まりました。。。

斜め読みでレスします。全く無関係かもしれませんし、既にご確認済みかもしれませんが・・・

http://php.net/manual/ja/function.umask.php 辺りは関与しないでしょうか?

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

chmod自体は使えましたか？

eccubeとは別に試してみて下さい。

homan様

レスありがとうございます。

>そもそも666で書き出されるということは、
>必ずどこかでパーミッションの設定をしているはず・・・・・・ですよね、、？

EC-CUBE側のソースを追ってみているのですが、該当部分では、特に書き出し時に666にパーミション設定するような記述は見当たりません。
なので、私も通常なら、644で書き出されるはずで、別の会社のサーバの場合は、644で書き出されているので、666で書き出されるのは、CPIのサーバ側の設定でそうなっているからでは？と思い、問合せしたのですが、CPIのほうでは、EC-CUBE側の問題と言われて、ノーサポートという返答しかもらえませんでした。

解決策としては、仕様ということで飲み込んで、手動でFTPで都度パーミション変更するか、EC-CUBE側のソースで、明示的にパーミション設定するか、と言うことになるのでしょうが、EC-CUBEのソース側（コミュ版です）で該当箇所と思われる箇所または代替で処理できそうな場所にchmod()をかませて見ているのですが、パーミションは変更されないのです。
私の記述のどこかが間違っているのか（この可能性が一番怪しい；）CPIのサーバでは、chmod()が効かないかのどちらかだと思います。

自分で選定するなら、サーバの仕様を色々見ていると、CPIは使わないだろうなと思いますが、こちらは、既に別システムで運用しているサーバで、今からサーバの変更を言い出すのは、ちょっと難しいので･･･

悩む･･･デス。

全然参考になるようなお話ではないと思いますが、
そもそも666で書き出されるということは、
必ずどこかでパーミッションの設定をしているはず・・・・・・ですよね、、？

そこを見つけて変更できれば解決するのかなぁと
ふと思ってしまいました。

そんな単純な話じゃないんでしょうか

----------------
このコミュニティでの投稿はボランティアの範囲に留めさせていただいています。個別の相談やカスタマイズは有償にて承っておりますのでご相談下さい。

[url=http://www.eccube-school.jp/]EC-CUBE

longman様

再度レス頂き、本当にありがとうございます！

なるほど、これはサーバ側に対応を求める問題ではないのですね。。。
サーバ環境に依存するものは、サーバ側の設定で変更してもらえるものと思っていました。（ルート権限預かりの専用サーバサポート月プランとあったので･･･）

では、こちらからCPIに依頼した調査その他は、失礼な内容だったのかも知れませんね･･･
ふーむ。

アドバイスいただいたコードの追加は、既に試しておりましたが、変化はありませんでしたので、Masashigeさんのおっしゃるように、CPIサーバでは、chmod()が効かない（もしくはプログラムの実行ユーザにその権限がない）のかもしれません。
もしくは、コミュ版では、もう少し別の箇所も関係するとかいうことがあるのかもしれません。

いずれにせよ、現象の発生する原因はわかったので、もう少しだけコードと修正箇所を変えてテストしてみようと思います。
（今のところ全滅です；；；）


Masashige様

>古い記憶なんでアレですが、昔CPIでchmod()が使えなくて
>EC-CUBEのインストール時に泣きながらFFFTPで権限変えた
>記憶が…。

なるほど。
有益な情報ありがとうございます。


総合すると、CPIサーバの仕様ということで、運用については、手動でFTPアクセスでパーミション変更しながら対応し、それが気に入らなければ、サーバを別の会社に契約するしかない、ということなのかもしれませんね...

お二方とも、有益な情報をありがとうございました！！

古い記憶なんでアレですが、昔CPIでchmod()が使えなくて
EC-CUBEのインストール時に泣きながらFFFTPで権限変えた
記憶が…。

プラン等も違うかと思いますが、一度EC-CUBE抜きでchmod()
試した方がいいかもです。

正式版2.4.3ですが

/data/class/pages/admin/design
にある
LC_Page_Admin_Design_MainEdit.php
のlfCreatePHPFile内で（420行目付近）


となっているものを

と一行追記する事で動作確認できました。

ちなみに、これはサーバー側に対応を求める問題ではないですよ。

longman様

今回もご回答いただいてありがとうございます。
ご確認が遅くなり、大変失礼しました。

試してみたのですが、上記では、今回は、うまくいきませんでした。
コミュ版では、この部分のソースの編成が少し違うので、該当箇所を探しながら、いくつかソースを変えて、もう少しやってみています。（進捗ありましたらご報告したします！）

サーバ側で、PHPの実行ユーザから新規ファイルの生成が行なわれた場合に、パーミションが666になってしまうため、動作不良にはつながらない部分でも、テンプレートファイルの生成やその他のところでも、いくつか同様の現象が発生しそうな気がします。
都度FTPでアクセスしてパーミションを修正する（またはファイルの更新は全てFTPで行なう）というのも、EC-CUBEの運用では実用的でないような気がしますので、なんらか対応方法がないか探っています。

サーバのほうの設定で、PHPの実行ユーザから新規ファイルの生成が行なわれた場合に、パーミションが644になるように設定することはできないものでしょうか？

CPIのサポートのほうでは、この問題は、EC-CUBEの問題なので、サポート外といわれましたが、この現象では今ひとつサポートの回答に全体的に腑に落ちないところを感じています。
自分もそれほど詳しいわけではないので、こういう現象をどちらの問題として区分けするのが一般的なのかは、よくわからないのですが、ただ、サーバの設定が、「PHPの実行ユーザからphpやcgi、tplなどの新規ファイルの生成が行なわれた場合に、パーミションがどうなる設定になっているか、それがCGIの実行権限と矛盾している場合に、それが正しいのかどうか」といった回答はあってよいのでは、と思っているのですが･･･

私は手動で更新してますが

LC_Page_Admin_Design_MainEdit.php
の195行目付近に下記を足せばいけるんじゃないですかね？