【雪だるま】bbsd⇔各cgi間のI/F仕様について考え・詰めていくスレッド
■ このスレッドは過去ログ倉庫に格納されています
雪だるま作戦において開発をすすめているbbsdでは、
+- [ フロントエンドサーバlive22x1 ] -- ユーザは
[ バックエンドサーバlive22 ] -+- [ フロントエンドサーバlive22x2 ] -- live22xという代表名で
制御プログラムbbsd +- [ フロントエンドサーバlive22x3 ] -- これらにアクセス
| | | dat直読みや、
dat subject.txt subback.html bbs.cgiやread.cgiやofflaw.cgi、
書きこみログ(芋掘り)ファイルなど (こちらは基本的に書き込み操作なし)
(書き込み操作はこちらで)
# 復帰/削除cgiなどについては、さてどっちかな => 今後の課題
という形で「ユーザの相手」と「各種ファイル処理」を複数のサーバに分業することにより、
さらなるパフォーマンスの向上を目論んでいます。
つまりこの場合、dat/subject.txt/subback.htmlは
バックエンドサーバで動作するbbsdというプログラムがリクエストに応じて生成し、
更新や場合によっては削除する形となります。
ということで、bbs.cgiをはじめとする従来２ちゃんねるで動いているcgiでは、
これらが同じサーバにあるつもりでファイル操作をしていましたが、
上記に示すように、少なくとも元本は同じサーバにはなくなるため、
何らかの形で対策を考慮する必要があります。
また現在、ID生成の種やSamba24や
timcount/timeclose等の規制関係で使用している一時ファイル等、
複数のフロントエンドサーバが同じ情報を、
何らかの形で共有する必要があるものもあります。
このスレッドではこれらの処理方法や実装方法について考えながら、
bbsdに持たせたい・持つべきな機能をあぶり出し、実装仕様を詰めていくことを目標にしています。 >>307
はや。おつです。
落ち着いたら、bbsdの入れ替え & APIへの組み込みをば。 そういえば、スレストの処理が微妙に従来と違うような。
いままでは、24レスのスレがスレストされたら、subject.txtには(24)って表示だったはずなのに、
>>310のスレは(25)って表示になってるですね。
あと、移転された場合も、従来は、レス数表示は移転された時点のレス数のまま、
スレタイも「移転しました。。。」ではなく移転される前のままだったけど、
移転しました。。。 (1)ってなってるように見えるです。
（通常復帰があった場合は確かにそうなるし、これは完全には確認はできてないですが、、） >>311 乙です．ただ......細かい bugfix をしましたので，お手数ですが再度更新お願いします＜bbsd
>##############################################################################
># スレをsubject.txt/subback.htmlから消去(dat落ち処理とかで)
># 入力: 板名、キー
>##############################################################################
>$errmsg = &PurgeSubject($ita, $key);
こういう形になってるとわかりやすそうですね．で，bbsd の purge コマンドの引数は
$keys となってるのがミソでして，もちろん単一のスレキーでもいいんですが，
複数のスレキーを ',' で区切って列挙しても Ok になってます．
>>312 それはですね......bbsd では，内部で保持している subject データが
dat の状態を正しく反映しているという前提で各種処理を行っているので，
dat の実際の状態と乖離したままにしておくと弊害が出かねないため
そのようにしています．また，dat の状態を正しく反映するためのオーバヘッドも
bbs.cgi に比べるとずっと小さくなっているということもあります． しつもん
誤爆レス削除の復旧も、お願いすれば出来たんですけど。
スレ削除と同じで。
レス削除・透明削除でも
どこかに削除前のdatは持っててくれてるのかしら。 >>313
更新したです。
で、purgeは複数指定できるですか。さすが。
>>314
なるほどです。
たぶん、呪文内で保存しているんだと思います。
保存の仕方により、bbsdやその上の部分(私が今組んでいる)のAPIで
フォローする必要があるかどうかが決まるのかな。
そのへん、どうなんですかね。> 知っている方
# 削除系は、技術情報がちと。 >>315
で、そういうことであればスレ削除と同じで、残す機構を用意すればよさげですね。
対象はレス削除と透明削除ですか。
で、>>307 にも言えるのですが、既に移動先に同じ名前のファイルがあったら、
どのようなことになるのかしら(EEXISTとかかな)。 少し更新。
http://mumumu.mu/bbsd-delete-apilist.txt
で、たぶん ResSakujo ResSakujo2 ResToumeiSakujo には
SureSakujo と同様、退避先パス名を追加するようになりそうな予感。 live22xではなく、live22に対して実行することになる呪文:
相当する呪文があるかどうかではなく、そういう機能を持った呪文ということで。
・SETTING.TXTをいじる呪文
・1000.txtをいじる呪文
・過去ログ削除の呪文
・強制dat落ちの呪文(手動むぎゅ)
・強制倉庫送りの呪文(★漏れとかの時に使用しているもの) → 動作確認済み by 私
・キャップを操作する呪文 → 動作確認済み by anglerさん
・削除(退避)したものを復活させる呪文
・dat落ちしたものを復活させる呪文
・芋掘り機 → おじさんから既に宣言あり で、たぶんですが、
・SETTING.TXTをいじる呪文
は、私の知っているものについてはlive22xで起動かけたら、
「この呪文はバックエンドサーバで実行してください」
っていうのを表示するCGIを、仕込んでおくかんじで。 >>316
>で、>>307 にも言えるのですが、既に移動先に同じ名前のファイルがあったら、
>どのようなことになるのかしら(EEXISTとかかな)。
現状では単なる rename() のエミュレーション，つまり上書きになります．
EEXIST になるようにした方がいいですかね．
で，レスあぼーんでもデータ退避ですか......あぼーんの度に dat 全体を
保存していると HDD を食い潰していきそうなんで差分で保存した方が
合理的だと思いますが，そうなるとどのようなフォーマットで保存すべきかとか，
あと退避したデータからロールバックする際に，直近のデータから復元するのは
問題ないでしょうけど，何世代も前のデータから復元する際に途中に透明あぼーんが
あるとそのままではずれてしまうでしょうし......そのあたり従来のあぼーん呪文では
どうしてるんでしょうね．
また，bbsd 以外のプロセスが dat を操作することに関してですが，例えば dat 落ちの
ようにファイル自体を rename() や unlink() するのは比較的安全だと思いますが，
dat の中身を書き換えるような操作には脆い面もあります．どのような操作かにも
依存しますが，レス追記とバッティングすると追記されたレスが消失するかもとか，
*.html 生成時には対応する dat を mmap() しますので，生成される HTML が崩れるとか
最悪の場合地雷 (SIGSEGV / SIGBUS) を踏むとかいった可能性もあるので......
となると，レスあぼーんのロールバックは bbsd 側で I/F を用意した方が
良さそうにも思いますが，従来の呪文でどのような処理をしているかがわからないと
なかなか具体的に作りづらいという面もあります...... >>320
> 現状では単なる rename() のエミュレーション，つまり上書きになります．
> EEXIST になるようにした方がいいですかね．
そうしていただけると助かります。
> そのあたり従来のあぼーん呪文では
> どうしてるんでしょうね．
いつだったかに管理人とおじさんに聞いた話を思い出しつつあるのですが、
確か「レス削除系でも、毎回全部dat全体を保存している」ということらしいです。
で、ファイルがあるかどうか調べて、
あったら何らかの規則で(見てませんが、例えば.0とか.1とか)、
保存しているんではないでしょうか。
「削除」という行為の、２ちゃんねるにおける「重み」を考えると、
そのぐらいはしているような、気がしますです。
で、管理人がそういった形でのデータの「あふれ」を気にするはずもなく、
おじさんが静脈系のプログラム(F22ともいう)を作って、
定期的に後始末をしていると、ぼやいていたのを聞いたことがあります。 >>320
>また，bbsd 以外のプロセスが dat を操作することに関してですが，例えば dat 落ちの
>ようにファイル自体を rename() や unlink() するのは比較的安全だと思いますが，
>dat の中身を書き換えるような操作には脆い面もあります．
私も、そう思っているです。
なので、特にレス削除系は、基本的にフロントからbbsd経由で
統一的に操作するようにしたいところです。
>となると，レスあぼーんのロールバックは bbsd 側で I/F を用意した方が
>良さそうにも思いますが，従来の呪文でどのような処理をしているかがわからないと
>なかなか具体的に作りづらいという面もあります......
確かに、そのとおりですね。
ロールバックも基本的に呪文でやっているはずなので(違うかもですが)、
これもフロントでやるようにしたほうが、いいかもです。
あるいはもし呪文でやってなかったなら、
そのための「復活の呪文」を新たに作って、それをぢぇんぬさんに配布してもらうかんじか。
# やっぱり、もう1段階覚悟を決めて、
# 標準セットの呪文を教えてもらって、読んでみるしかないのかなぁ、、、。 $key = スレキー;
$nowtime = UNIXたいむ;
ログ保存($key$nowtime);
一度削除系CGIの仕様を詳しく聞いた方が・・・。
俺の口からはいえない。 >>323
なるほど。
どこのどなたかは存じませんが、ありがとうございます。
同一秒の間に同じスレへの削除が起こらなければ、いけるようになっていると。
で、そうやっているってことは、
昔のbbs.cgiのスレ立て重複防止装置のところを書いた人と
仮に同じ人が書いているとすれば、
$newtimeを+1して、、、ってのを、大丈夫になるまで繰り返しているんでしょうね。
ぢぇんぬさんに、相談してみるです。 呪文だけ教わっても、アカウントがなければ作業は出来ないから
作業を押し付けられることはないと思うんですが（ぼそ）
削除ログのcgiをいじられる上で気になるのは、
書き込みログとの整合性をどこかで取ってる筈なので、
そちら（IP・リモホ）の消しすぎや漏れが出ないかどうか、です。。
ご相談のメールを、ぢぇんぬさんと管理人に発射したです。 >>325
第一段落:
某ホテルで「(アカウントは)いつでも作るですよ」って管理人に言われて、
ものすごい勢いで、首を横に振った私がいるです。
第二段落:
そうですね。
書き込みログはバックエンドにしかないので、そのへんも問題になる可能性ありか。
まずは「ご相談」のお返事を見てから、次の行動をってかんじで。 うはｗ 予想通り＞「いつでも」＆「ものい勢いで」
あとは「削除の呪文を唱えた人のログ」もあるはずなので
そちらの方の記録もできるかってことですかね。
いろいろお疲れ様です。宜しくお願いします。 >>329
削除でログが消える期間が短くなる、と聞いてますよ。
329さんがcgi制作の中の人ならごめんなさいですが。 >>328
>あとは「削除の呪文を唱えた人のログ」もあるはずなので
>そちらの方の記録もできるかってことですかね。
そっちは、bbsdのほうで対応するためのI/Fが用意されているです。 スレ削除（退避）時に同一パス名が存在した場合に EEXIST にするのは対応完了です．
あぼーん/ロールバック関連については，もうちょっと様子見で...... >>332
おつです。入れ替えてきます。
> あぼーん/ロールバック関連については，もうちょっと様子見で......
こちらも了解。 >>333
完了です。
- || (fd_new = open(new, O_WRONLY|O_CREAT|O_TRUNC, 0644)) == -1
+ || (fd_new = open(new, O_WRONLY|O_CREAT|O_EXCL, 0644)) == -1
なるほど。
# bbsd.cをちびちびと読み始めようかと思っていたりするんですが、
# なにぶん、中身がすごくて(いい意味です)。
# 何というか、コメントではなく、中身をもって語らしめよ、みたいな。 >>334 確かにコメントがほとんどないのは不親切かも......w
とにかくがーっと書いててコメントまで気が回らなかったんですが，
bbsd.c のおもりをどなたかに委ねるとかいうことになったら，
わかりやすいようにしなきゃですね． >>335
> bbsd.c のおもりをどなたかに委ねるとかいうことになったら，
> わかりやすいようにしなきゃですね．
どきどき。
面白いと感じていただける間は、ぜひお願いしますです。
私も、面白いと感じていられる間は、やりますです。
で、bbs.cgi は「おじさんや私じゃなくても大丈夫な状態にする」ことが目的だったので、
もうしつこいぐらい、コメントにつぐコメントだらけになっているです。
%wc -l bbs-main.cgi
4569 bbs-main.cgi
%grep # bbs-main.cgi | wc -l
1193 >>336 まぁ，よほどのことがなければ自分の側から投げ出すってことはないと思うんで．
もっとも，天変地異はいつ起こるかわからないとか，そういうレベルの話だと神のみぞ知る，ってところですが． >>337
それは、お互い様すね。
今日はたぶんここはこのぐらいで、たぶん、また明日以降に。
# さっきのメールの返事、管理人からはいつもどおりの「おつです。おつです。」、、、。 >>338 乙でした．ではまた明日以降にでも．
># さっきのメールの返事、管理人からは(ry
(w 4500 行かぁ・・・
大分類して、requireとかuseにするという手もあるのかな。 >>341
これはこないだの某ホテルでも、話題になったすね。
そろそろ、やる時期かも。 ぢぇんぬさんから、>>324 のお返事をいただきました。
ということで、ぼちぼち、すすめていこうかなと。 呼ばれて飛び出て（ｒｙ
こら、そこ。
冬休みとか言わないように。 >>343
乙です、超乙です。鬼乙です。
なんかあったら電波飛ばしてくださいですー。
私のほうでも出来るだけここ覗くようにしますです。 >>344
でたなー。
>>347
どもです。ハードな作業いつもおつです。
で、メールでのお返事をここでしてしまったりしますが、
このスレはoperateの中でもハードコアなほうらしいので、
スレの技術的な内容が仮にアレだったとしても、
あんまり気にすることはないと思うです。
ようは、できるだけこれまで通りに、
場合によってはこれまでより効率よく安全に使えるといいなという、
単にそれだけのことです。
今後、作業を徐々にすすめていくことになると思いますので、
呪文を使う上で何か不具合があったとか、妙なことが起きたとか、
これまではこうやってたけどこういうことができるといいなとか、
そういうことがあれば、忌憚なくここに書いていただけると。
# それらに対応できるかどうかは、別の問題とゆうことでひとつ。 > このスレはoperateの中でもハードコアなほうらしいので、
一番ハードコアですよ、ここ
perlの追っかけなど、技術動向に強い人じゃないとついてけない いや、あのアンカーはあっている（ということにしよう） いんどメーターを起動。結果９５いんど。どうみても（ｒｙ さて、ここもぼちぼち動かそうかなと思います。
本格対応は、お雑煮食べながらという感じになりそうな予感ですが。
で、やはりどうも必要になりそうなので、
とりあえず汎用のファイルコピー用APIを、bbsd側で作っていただけるとありがたいです。
パス1 を パス2 に単純にコピー、
パス2が既に存在したら EEXIST エラー、といった感じで。 >>360 そうですね．ロールバック対応が完了すれば，呪文も一通り対応完了でしょうし．
>とりあえず汎用のファイルコピー用APIを、bbsd側で作っていただけるとありがたいです。
>パス1 を パス2 に単純にコピー、
>パス2が既に存在したら EEXIST エラー、といった感じで。
了解です． ファイルコピー:
my $errmsg = bbsd($srcpath, 'cp', $dstpath, "$logfilename:$logline");
実装しますた． >>362
おつです、おつです。
今何か超速い番組やってるんで、
入れ替えは、のちほど。
# 元気に動いて、実況を支え続けているです。はい。 bbsd 更新したです。
これでひととおりのAPIがそろった気がするので、
こちらも、ぼちぼちと。 おふろ入っている間に思いついたので。
Samba24とか、timecount/timecloseとかの
DB管理系だけを、別のbbsdでお守りすることにして、
そのbbsdは、フロントエンドのどれかに持たせるというのはどうかなと。
で、つまり、bbsdのDB管理系部分だけの機能を有効にするような
起動オプションがあると、うれしいのかもなぁと。
ということで、本日はここまでで。 >>367 の心は、
こういうふうにすれば、バックエンドのbbsdを
少しでも軽くできるんじゃないかなぁと、そうゆうことで。 いずれにせよ面白そうなので、ちと考えてみるです。
というかたぶんここで、例によって。
・野球系・サッカー系を一かたまりにして、効率よく
・www/www2/menuをグレードアップ
あたりが命題で、すぐ使えるのは、
・live16 live18 live20
あたりですか。 >>367-368 そういうことであれば，起動オプションを新設するまでもなく
現状の bbsd を普通に立ち上げればいいと思います．
板ディレクトリと SETTING.TXT があって subject.txt がない状態なら，
そのままで DB 管理専用 bbsd として使えるかと．
DB 管理系 API を呼び出すだけなら，subject や dat の操作は一切行いませんし． >>371
おぉ、すばらしいです。
あとで、やってみるです。
これで、規制系DBをフロント(というか別サーバ)にもっていけると。 対応したです。
これで、live22のbbsdからこれらの仕事を分離できたと。
560 名前： ◆MUMUMUhnYI [sage] 投稿日：2005/12/27(火) 04:23:13 ID:hh69QxeR0 ?
# 051227 bbsd複数体制(書き込み・IDの種用とDB保持用)に対応
# Samba24、●スレ立て、timecount/timecloseのDBのおもりを別サーバで
# これらに関してはbbsdがダウンしていてもとりあえず書き込みは可能に by む >>373 により、Samba24のデータをlive22x1のbbsdで面倒見るようになったので、
例の数値が出るサーバが、live22x1に変更になったです。＞どくどくさぼてんさん 今後の作業をすすめていく場所ができました。
荒らすか(仮)＠2ch掲示板
http://snow.2ch.net/alaska/
ローカル雪だるまで動いています。
各種呪文等は、今後ここでごにょごにょと対応を進めていくことになるのかなと。 >>375
削除の呪文を唱えるのに、かなり手間取るようなのですが
せめて板名を変えてもらえませんか？
現状の板名では
荒らし依頼や電番・サイト攻撃などの書き込みが集まる悪寒がします。
運営の人には面白い駄洒落なのかもしれませんが
荒らし公認ととられかねない板名は、やめて欲しいです。 >>376
> 削除の呪文を唱えるのに、かなり手間取るようなのですが
そうなんですか。
snowは「ローカル雪だるま」(= datそのものはsnowサーバに普通に存在)なので、
スレ削除とかスレ移動等の後に復帰の呪文が追加で必要になりますが、
呪文自体が「かなり手間取る(例えばlive22x => live22にしないと効かない)」ことは、
ないと思うです。
板名ですが、おじさん流の洒落すね。
私は正直あんまり気にしてないですが、ちょっとびっくりしたです。
(フォルダ名alaskaをお願いしたのは私ですが、その洒落は私は全く思いつかなかった) >>377 に自己突っ込み
で、もし仮に「かなり手間取る」が「別途復帰の呪文が必要」のことだとしたら、
それは「このとおりです鋭意なんとかします今は許してください」しかないです。
ごめんなさい。
ﾄﾞｳﾓｽﾐﾏｾﾝ、ｺﾉﾄｵﾘﾃﾞｽのAA↓ 要するに>>376さんは
削除が大変なんだからせめて削除対象になるレスを増やすような板名はやめちくれ
ってことかな そういう話ですか。>>379-380
SETTING.TXTを変えるのは私でもさっくりやれますが(板名にこだわりないし)、
kakolog.html とか kako/ とかは、どうすればいいのかな。 とりあえず、SETTING.TXTだけ変えてみた。 隠し板扱いだし、そもそも書き込み自体があんまりないような気がする。
そんなに気にしなくてもいいんじゃないの？ 対外的（要請板取り扱いみたいなの）があるとやっぱり問題かとも思うけどねぇ
まあないか。 探知はされてるよ
http://snow.2ch.net/test/read.cgi/alaska/1135699588/5-6
>>381
＞kakolog.html とか kako/ とかは
これそこらじゅうでむちゃくちゃになってるから
窓口決めといて ＞◆cZfSunOs.さん＆rootさん、関係各位
本年もよろしくお願いします。
live22xのsage復帰ですが、一度で上手くいかずに何度か呪文を唱える事になりました。
呪文を唱えるたびに、42→36→34→33のようにsubjectのスレッド数が変化しました。
(上手くいっていれば一度で42→33になるはずです)
何らかの問題が潜んでいるのか、今回だけなのかわかりませんが、とりあえずご報告します。
またlive22x復帰する機会があったら、挙動をよく見ておきます。
http://qb5.2ch.net/test/read.cgi/operate/1127134565/686-688
よろしくお願いします。 >>386 こちらこそよろしくお願いします．
で，ご報告ありがとうございました．う〜む......sage 復帰でスレが subject から消される条件は
if (stat(*worker->paths, &st) && errno == ENOENT)
つまり dat ファイルへの stat() が失敗しかつ errno が ENOENT な場合ということなので，
何らかの原因で ENOENT 以外だったんでしょうか．いずれにせよこのあたり要観察ですかね．
# 番外編として，本来マルチスレッド環境で MT-Safe であるべき errno に虫がいるかも
# ってのもあり得なくはないのかも...... >>386-387 について......「要観察」といっても，現状だと ENOENT 以外が発生しても
何が起きたか見当もつかないんですよね．ということで，ENOENT 以外が発生したら
エラーリターンになる（$errmsg にメッセージを返す）ようにしますた． >>388
お、年始早々bbsdの更新ですか。
やっておくです。
APIのほうでも、ちゃんとエラーチェックしないといかんということですね。 >>389-391 乙です．まぁ $errmsg をそのまま表示でいいんじゃないかと思います．
どちらにせよ現状では何が起きたのかもわからないので，それ以外やりようがないでしょうし． datのレス数とsubject.txtのレス数が違っていた場合に、スレに
書き込んだ時の、subject.txtのレス数の処理はどうなっていますか。
通常のbbs.cgiでは、subject.txtのレス数に関わり無く、書き込む度に
datからレス数を数え、その数をsubject.txtに書き込んでいた為、
subject.txtのレス数が異常でも、そのスレに書き込めば直ったのですが。
というか、これ。
http://live22x.2ch.net/test/read.cgi/eq/1136722083/
subject.txtのレス数がdatより1多い状態になっているのですが、
スレに書き込んでも、subject.txtのレス数がそのまま+1されるだけの
ようで、はて、どうしたものかと。
通常の板復帰では、subject.txtに載っているスレは、レス数を数えて
直してはくれないはずですし。
古い完全復帰なら直してくれた気はするけど、どうだったかな。 >>393 う〜む......datがおかしくなった原因は不明ですが......
# 透明あぼーんがあったとか？ bbsd を経由しない形で dat の内容が
# 変更されるようなことがあれば bbsd 的には想定外の事態ではあるんですが......
復帰（bbsd の repair コマンド）を実行すればカウントし直します． >>393-394
うーむ、呪文対応をはやいとこすすめないと。 どもー。
こちらさんの復帰はレス数も直してくれるのですね。
では、復帰を依頼する方向で。 管理人の方々お疲れ様でつ。
今から工房の携帯から妄想がたれ込みますが脳内阿保ーんお願いします。(じゃあ書くのやめれとか言わんでくれ
)
どっかにスレ情報書き込んであるデータ生成すれば板設定変更出来るlocal.info作って見たり。
なかったらデフォルト呼び出し。
アクセス権に色々背負わせてみるのも面白いかもグループとかは使わない？から[0-7]でそれぞれにスレスト･1000越え･512K制限･普通･隠し･ゴミ箱行き･移動とか？
そうするとゴミ行きが分かり安いかな？
呪文唱えるときはbashでまとめたいなぁ。
#タイムアウトを
#
##タイム
##アウト
##ヨヨイノ
##
##
##ブーン(AAry
#
#にして欲しい。みたことないけどw 【焼きもち】自治スレ
http://live22x.2ch.net/test/read.cgi/news/1144769649/333
333 名前：FOX ★[sage] 投稿日：2006/04/12(水) 05:16:29.51 ID:???0
しかし
live22 は特殊なので使われていないキャップあぶり出し機能が動いていないことに
気がついている
なるほど。
bbsd で touch する I/F は前に作ってもらったので、技術的にはできるはず。 >>399
汎用 touch ルーチン(スレッド924用)を流用することで、対応できました。
これで、plus 系もやろうと思えば雪だるまにできるはず。 >>401
お前は死刑だ 不倫関係があったのでこれより死刑に処する ｱﾘの巣ｺﾛﾘってあるじゃん
蟻の行列にﾎﾟﾝと置くと一瞬ﾋﾞｯｸﾘして列が乱れる
邪魔だなと言わんばかりに迂回する列が出来る
そのうち好奇心旺盛な一匹がｱﾘの巣ｺﾛﾘに入る
そいつをﾏﾈして何匹も入る
毒とも知らずにﾂﾌﾞﾂﾌﾞを運び出す
一匹が一粒づつ
いつのまにか行列はｱﾘの巣ｺﾛﾘが折り返し地点になる
黄色い粒と黒い蟻が作り出す模様は綺麗で見てて楽しい
一匹が一粒づつ丁寧にせっせと毒の粒を運ぶ
せっせとせっせとせっせとせっせと
蟻さんって働き者だなと思う
俺も頑張らなきゃなと思う
次の日あれほど沢山いて俺を困らせた蟻が一匹もいない
ほんとにいない
探してもいない
泣きたくなった
このﾚｽを見た人は4日後にあなたの大切な人がいなくなるでしょう
それが嫌ならこのﾚｽを5つの板にｺﾋﾟﾍﾟしてください
信じるか信じないかはあなた次第です ■ このスレッドは過去ログ倉庫に格納されています
