気持ちは伝わります。
copy /y logfile.log.9 logfile.log.10 copy /y logfile.log.8 logfile.log.9 copy /y logfile.log.7 logfile.log.8 copy /y logfile.log.6 logfile.log.7 copy /y logfile.log.5 logfile.log.6 copy /y logfile.log.4 logfile.log.5 copy /y logfile.log.3 logfile.log.4 copy /y logfile.log.2 logfile.log.3 copy /y logfile.log.1 logfile.log.2 copy /y logfile.log logfile.log.1
いや、このコードが言わんとしてるのは、10世代保持でそれ以上は消すってことっしょ。
そういう運用設計自体は至極当たり前に行われるものだし、別に突っ込むものでもない。
そこは置いとくとして、実装はtoo too buggyですな。
このままだとlogfile.logが増え続ける一方なので、ローテートログも、延々とサイズが増え続けちゃうし、
ローテートの都度毎度毎度複製でディスクIOを発生させまくるし。。
ループ記述をせずにstaticに書き連ねてる辺りにも、そこはかとない 感情を覚えます。
> なぜcopyなのか・・・
想像に難くない。
「renameしたいのに、プログラムがlogfile.logを開きっぱで手放してくれないんだから複製取るしかないじゃん。」
とでも考えたんでしょう。
> renameしたいのに、プログラムがlogfile.logを開きっぱで手放してくれない
時点で、そのログを吐くソースコード側に問題があるなw
renameしたいのに、プログラムがlogfile.logを開きっぱで手放してくれない 時点で、そのログを吐くソースコード側に問題があるなw
誤解して欲しくないのだが「プログラムファイルがログファイルを開きっぱなしで手放してくれない」という運用は、ある。
ログファイルを開くコストがバカならない現場というのは、間違いなくあるのだ。
ただし "logfile.log"といった絶対に変化しない1つのファイルに書き続けるというのは、ソースコードというより設計に問題がある。
とはいえ。「必ず定期メンテあるし。それまで1つのファイルに書き続けるよ」というのも、考えられないことではない。
たしか私の経験した現場では「ログ抽出ツール」があって、何十ギガのログファイルを対象にしていたと記憶している。(...考えたらあれは、ログファイルではなくダンプファイルだった)
もっとも……その場合は、そもそもローテートなんてしないが。
ちょっとこのスクリプトだけでは判断できないんだけど、設計上 logfile.log という一つのファイルにログをひたすら追記していくだけのログの取り方をしてるなら、これはローテートしたことになってないですよね。しまいにはサイズだけ馬鹿でかい名ばかりのログファイルが 10 個できてディスク容量を圧迫するだけ。
ローテートさせるからにはそれなりの理由(ログは 1 日とか 1 週間とかの単位で区切るとか)があるはずで、それならこんなことしないで Apache Logging Service (Java なら log4j)とかでも使えば ? ってことになると思うんですが。
「ねえママ、10こ以上前のろぐふぁいるはどこへいっちゃうの?」「お空でお星様になるのよ。」