AMUMUさま有力な情報どうもです。
調べてみてもrenameは見つからなかったのに、なんか残っているっぽいなぁ〜と疑っていました。
やっぱり残るんですね。

また、今更ながらですが・・・
ファイルサイズがMAXサイズに全然達していないログファイルがチラホラできあがっておりました。
原因はfile_exists()で、キャッシュを読み込んでしまっているため、何度もローテーションが発生していた為です。

clearstatcache()呼びまくるのも考えものなので、できればphpの
・realpath_cache_size
・realpath_cache_ttl
の設定を変更して試そうかと思いますが、0にしちゃうと他の処理で問題がありますでしょうか？

file_existsで実際にファイルが存在する場合はrealpathキャッシュが一番効いて速度的には効果が高い所ですから、良さもあるので中々難しいところですね。

>clearstatcache()呼びまくるのも考えものなので、できればphpの
>・realpath_cache_size
>・realpath_cache_ttl
>の設定を変更して試そうかと思いますが、0にしちゃうと他の処理>で問題がありますでしょうか？

問題ありです。
EC-CUBEは読み込むファイルが多く、Smartyとの絡みもあり、ファイルの存在チェック等も多いです。realpathキャッシュの効果は高いと思います。0はあまりオススメしません。ttlを下げるぐらいが妥当な線かと思います。
realpath関連の値を変えるぐらいならclearstatcacheを呼びまくる方が処理論的には美しいとともに効率的かつ正しい使い方かと思います

>また明日調べてみますが・・・
>そろそろ私のようなPHP初心者には限界のレベルです。

全然初心者とは言えない十分なネットでの調査やご報告でEC-CUBEを、よりよくする為にもなっていますし、実際に問題も解決に近づいていて素晴らしいと思います

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h

> renameはキャッシュ使用対象と5.1台では一時期書いてあったようです。問題が多かったのか5.3系では対象外の模様(マニュアルを信じるならば）。

そうなると、5.1系では rename で stat の情報を利用していた時期があると考えられますね。おそらく、patapata 様の環境で、rename 時に警告が発生した事象も、これが原因のようですね。

そもそも、現マニュアルでは、rename が警告を発するという記述も内容ですし。(あっでも、5.2系 Windows では、発生しました。)

Windows 版が行なっているような動作を、UNIX 系にも適用しようと試みたんですかね。

しかし、それだけでは説明が付かない部分もあるので、もう少し探求が必要となりそうですね。

# PHP の C ソース見れば明確になりますが、あれ見ると PHP を使うのが怖くなるので、やめておきます。


> 唯一ぶれていないのはunlinkは必ずキャッシュをクリアするという仕様でしょうか
> 信じられるのはunlinkだけと思ってます・・・(苦笑

もしや、rename のときって、第1引数($oldname)側のキャッシュクリアしていないんですかね・・・

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

> また、今更ながらですが・・・
> ファイルサイズがMAXサイズに全然達していないログファイルがチラホラできあがっておりました。
> 原因はfile_exists()で、キャッシュを読み込んでしまっているため、何度もローテーションが発生していた為です。

昨日お書きいただいたコードでしたら、clearstatcache() を直前で呼んでいますので、キャッシュの影響は無いような気がします。


> clearstatcache()呼びまくるのも考えものなので、できればphpの
> ・realpath_cache_size
> ・realpath_cache_ttl
> の設定を変更して試そうかと思いますが、0にしちゃうと他の処理で問題がありますでしょうか？

今回の問題は realpath のキャッシュではなく、stat のキャッシュが関与している気がするので、効果は得られないかもしれません。(実験としては面白いアプローチだと思いますが。)

PHP 5.3 だと、clearstatcache() 呼びまくっても全然問題なさそうですが、5.1 だと若干抵抗はありますね・・・ まぁ、EC-CUBE 全体の処理から考えたら、さほどパフォーマンスの低下は無いようにも思います。

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

PHPのソースコードを軽く見てみました

5.1の途中にてrenameのキャッシュクリア処理が実装された模様。
該当リビジョンログ＞ http://svn.php.net/viewvc/php/php-src/branches/PHP_5_1/TSRM/tsrm_virtual_cwd.c?r1=33331&r2=34528
それまではTSRM配下に処理が無いのでキャッシュクリア処理は無かったようです。

5.2は5.1の変更状態そのまま
一応STATキャッシュクリアは移動前後のファイル両方に掛かっている模様。


5.2→5.3においてWindowsでの動作不具合の対策が(やっと)されている

http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/TSRM/tsrm_virtual_cwd.c?r1=249483&r2=258373

----------------
EC-CUBE公式エヴァンジェリスト
EC-CUBEインテグレートパートナー (株)スピリット・オブ
移転・拡張・高速化・問題解決
各種カスタマイズ・支援依頼承ります。
[url=h

ひぃーー　TSRM ですか。
いよいよ、スレッド絡みですかね・・・

しかし、非スレッドセーフだと、5.3 では生の rename を呼んでるような。

あっ、でも php_plain_files_rename で、とかやってますね。(PHP 5.3.3)

ってか、「and realpath cache」なんですね・・・ うむむ・・・

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

お返事が遅くなりまして申し訳ありません。
seasoft様、AMUMU様たくさんの情報どうもありがとうございます。

以下について
＞昨日お書きいただいたコードでしたら、clearstatcache() を直前で呼んでいますので、キャッシュの影響は無いような気がします。
すみません。説明が足りてませんでした。上記は、改版前で起きていた現象です。
板の一番最初に書きました。以下のことがらについての自己レスとなります。
＞＞rename処理が何重にも走っているようです。
にかかってきており、該当の処理はrenameとは別で、filesizeのキャッシュの問題になりますので、それはPHPのVerに関係なく
修正されていないかもと思い、あげさせていただきました。(調べてみた限りでは、修正されている節はありませんでした。)
filesize関数のキャッシュのみ効いている場合は、エラーは起きませんが、MAXSizeに到達しない場合でも、
ログローテーション処理が連続して発生するかと思われます。

以下について
>・realpath_cache_size
>・realpath_cache_ttl
上記設定を0に設定のみの修正で試してみたところ、ワーニングは発生しませんでしたが、
filesizeでキャッシュを読み込んでいるのか・・・ログローテーション処理が発生しまくり、MAXに達していないファイルが
多数できあがりました。

以下について
>if ( !file_exists($path) || filesize($path) <= $max_size) return;
!file_exists($path)を入れないと、いくらキャッシュをクリアしてもワーニングが発生するようです。
おそらく書き込みでどっかしっぱいしてるのだと思われますが・・・
もう時間がないので放置です。ごめんなさい。


最終的に以下のようになりました。
----------------------------------------------------------
function gfLogRotation($max_log, $max_size, $path) {

// ファイルが最大サイズを超えていない場合、終了
clearstatcache();
if ( !file_exists($path) || filesize($path) <= $max_size) return;
// アーカイブのインクリメント(削除を兼ねる)
for ($i = $max_log; $i >= 2; $i--) {
$path_old = "$path." . ($i - 1);
$path_new = "$path.$i";
clearstatcache();
if (file_exists($path_old)) {
clearstatcache();
rename($path_old, $path_new);
clearstatcache();
}
}
// 現在ファイルのアーカイブ
clearstatcache();
rename($path, "$path.1");
clearstatcache();
}
----------------------------------------------------------
(私はこんな風にしちゃいましたが、最後にファイル作った方が安全かもしれません・・・)


その他
chroot(), clearstatcache(), rename(), rmdir(), unlink()を呼び出したタイミングで、realpath cacheはクリアされる
とかってらしいですね。まぁVerによって大分動作が違うみたいなので、正確かどうかはわかんないですけど。
しかしfilesizeは、やはり見当たらないので、もしかしたら皆さんの環境でもファイルサイズがおかしなログが作成されているかもしれません。

以上です。どうもありがとうございました。