C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[55]: ディレクトリの排他アクセス [2]

(過去ログ 40 を表示中)

[トピック内 142 記事 (41 - 60 表示)]　 << 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 >>

■20198 / inTopicNo.41)

　Re[23]: ディレクトリの排他アクセス

▼■

□投稿者/ す (18回)-(2008/06/07(Sat) 14:29:57)

■No20197 (れいさん) に返信
> 現実に可能なのに、Win32APIにないのかが疑問なのです。

それは簡単です。必要性がないからです。

引用返信 編集キー/

■20199 / inTopicNo.42)

　Re[22]: ディレクトリの排他アクセス

▲▼■

□投稿者/ れい (608回)-(2008/06/07(Sat) 14:44:55)

■No20196 (すさん) に返信
> ■No20184 (れいさん) に返信
>>>>エントリの属性を適用する際に整合性を維持することもできるとか。
> >>どういうことでしょう？
>>
>>ディレクトリのFileAttributesを設定して次にCreationDateを変更するときとか、
>>一度に出来ない作業の場合は排他で開けると整合性を維持できます。
>
> >>その「整合性を維持できます」の意味というか、価値が分からないのですが、
> >>逆に不整合というのはどういう状況で、どういう悪影響が考えられるのですか？
>>
>>そのまんまです。
>>更新時刻や属性を重要なメタデータとして扱いたいときに、できたら便利なんですが。
>>今は出来ないので違う方法を使わざるを得ない。
>
> なにが問題なのか、なにが便利なのか、ちっとも分からないですが、
> もうすこし明確にできませんか？

むー？
これ以上明確に書くのは私には難しいですが、がんばってみます。

ある瞬間において、
ディレクトリの作成日時、更新日時、アクセス日時やファイルの属性が
適切な値に設定されてる状態にしたい場合です。
ハンドルを排他で開くことが出来るなら簡単にできますが。
ディレクトリをハンドルで扱わないのであれば、
TxFなどの違う方法がないと不可能です。

どうしてそうしたいのか、という話なら、例えば…

二つのディレクトリの同期を行いたい場合で、
内容ではなく「最終更新日時」で同期したい場合などはどうでしょう？

あと。これも何回も言ってますが。
今現在それができなくて、なんとかしたいというわけではありません。
なんでこういう仕様になっているのか、理由を知りたいのです。

「これで問題ないから」では理由になりません。
「こうでないとうまくできない」というのが理由です。

「パフォーマンスが落ちるのを懸念した」というは合理的理由ですが、
そうならばなぜOS内部で利用しているのか、という理由が知りたいです。

「行儀の悪いプログラムをユーザーが作るのを懸念した」というのも分かりますが、
それならばそれはファイルロックに対しても同様ですので、納得できません。

引用返信 編集キー/

■20200 / inTopicNo.43)

　Re[24]: ディレクトリの排他アクセス

▲▼■

□投稿者/ れい (609回)-(2008/06/07(Sat) 14:48:17)

■No20198 (すさん) に返信
> ■No20197 (れいさん) に返信
>>現実に可能なのに、Win32APIにないのかが疑問なのです。
>
> それは簡単です。必要性がないからです。

いやだから…。
ちゃんと読んでください。

最初から言ってますが。

必要性がないでは理由になりません。
少なくとも、ファイルシステムの実装を考えるなら、
ディレクトリに対してハンドルで扱ったほうが合理的なのです。

それを、敢えて変更した理由が知りたいのです。

必要がないなら、ファイルシステムの実装をそのままラップして、
ディレクトリをハンドルで開く実装にすればよかったはずなのです。

なにか積極的理由でディレクトリのハンドルを隠蔽しているのです。

引用返信 編集キー/

■20201 / inTopicNo.44)

　Re[23]: ディレクトリの排他アクセス

▲▼■

□投稿者/ す (19回)-(2008/06/07(Sat) 14:54:27)

■No20199 (れいさん) に返信
> ある瞬間において、
> ディレクトリの作成日時、更新日時、アクセス日時やファイルの属性が
> 適切な値に設定されてる状態にしたい場合です。

適切な値と言われても、どういう値が不適切なのですか？

> どうしてそうしたいのか、という話なら、例えば…
>
> 二つのディレクトリの同期を行いたい場合で、
> 内容ではなく「最終更新日時」で同期したい場合などはどうでしょう？

だから、どういう状況でどういうトラブルが生じるのですか？

引用返信 編集キー/

■20203 / inTopicNo.45)

　Re[25]: ディレクトリの排他アクセス

▲▼■

□投稿者/ す (20回)-(2008/06/07(Sat) 15:02:55)

■No20200 (れいさん) に返信
> 少なくとも、ファイルシステムの実装を考えるなら、
> ディレクトリに対してハンドルで扱ったほうが合理的なのです。

すみません。ちんぷんかんぷんです。

FindFirstFileはハンドルを返しますが？

引用返信 編集キー/

■20205 / inTopicNo.46)

　Re[24]: ディレクトリの排他アクセス

▲▼■

□投稿者/ れい (610回)-(2008/06/07(Sat) 15:12:12)

■No20201 (すさん) に返信
> 適切な値と言われても、どういう値が不適切なのですか？

プログラマが望んで設定したい値が「適切な値」で、
プログラマが望んでいない値が「不適切な値」です。

>>どうしてそうしたいのか、という話なら、例えば…
>>
>>二つのディレクトリの同期を行いたい場合で、
>>内容ではなく「最終更新日時」で同期したい場合などはどうでしょう？
>
> だから、どういう状況でどういうトラブルが生じるのですか？

最終更新日時二つのディリレクトリを同期したい場合に、
ソースディレクトリD1の更新日時Aと
ターゲットディレクトリD2の更新日時Bを比較して、
ソースの方が新しいならファイルをコピーして…、
で、最後にターゲットの更新日時をソースの更新日時Aにするわけですが、
書いてる間に誰かがD2に対して何か作業するかもしれません。

それを更新日時で検出したいとするなら、
「ファイルを書き込んでも親ディレクトリの更新日時を変更しない」
か、
「『親ディレクトリの最終更新日時を読んで、値によってはそれを変更する』という作業をアトミックに操作する」
の二つが必要になります。

「適切」、「不適切」の話は、後者のような話です。

「ディレクトリの更新日時が、XXX以前であればXXXに設定する」
みたいな作業は、Win32APIでは厳密には出来ないのですね。
似たようなことがいろいろとディレクトリではできないのです。

引用返信 編集キー/

■20206 / inTopicNo.47)

　Re[26]: ディレクトリの排他アクセス

▲▼■

□投稿者/ ちゃっぴ (116回)-(2008/06/07(Sat) 15:13:48)

■No20203 (すさん) に返信
> FindFirstFileはハンドルを返しますが？

返すのは file search handle です。
ここで言っている directory handle とは別物です。

引用返信 編集キー/

■20207 / inTopicNo.48)

　Re[17]: ディレクトリの排他アクセス

▲▼■

□投稿者/ ちゃっぴ (117回)-(2008/06/07(Sat) 15:15:36)

■No20191 (ネタ好きさん) に返信
> 「ディレクトリの更新日時が、XXX以前であればXXXに設定する」
> みたいな作業は、Win32APIでは厳密には出来ないのですね。
> 似たようなことがいろいろとディレクトリではできないのです。

現在だと VSS (Volume Shadow copy Service) 使っとけ！って感じですかね。

引用返信 編集キー/

■20208 / inTopicNo.49)

　Re[26]: ディレクトリの排他アクセス

▲▼■

□投稿者/ れい (611回)-(2008/06/07(Sat) 15:23:14)

■No20203 (すさん) に返信
> ■No20200 (れいさん) に返信
>>少なくとも、ファイルシステムの実装を考えるなら、
>>ディレクトリに対してハンドルで扱ったほうが合理的なのです。
>
> すみません。ちんぷんかんぷんです。

ええ:D
私もちんぷんかんぷんです。
話が通じたときにはきっとお互いにいろいろ勉強になってるはずです。

> FindFirstFileはハンドルを返しますが？

FindFirstFileが返すハンドルはディレクトリのハンドルではありません。
それはWin32サブシステムが内部で保持してるメモリのハンドルです。

FindFirstFileは恐らく内部で以下のような作業をしています。

1 メモリを確保し、そこにパスを記録する。
2 NtCreateFileでディレクトリハンドルを開く。
3 ZwQueryDirectoryFileか何かでディレクトリエントリを複数取得する。
4 ディレクトリハンドルを閉じる。
5 最初の一個を除き、残りをメモリに設定する。
6 最初の一つと、メモリのハンドルを返す、

FindNextFileはこんな感じ。

1 与えられたメモリハンドル内にあるディレクトリエントリを一つ取得する。
2 取得できたなら、メモリから削除してから、それを返す。
3 ないならNtCreateFileでディレクトリハンドルを開く。
4 ZwQueryDirectoryFileか何かでディレクトリエントリを複数取得する。
5 ディレクトリハンドルを閉じる。
6 最初の一個を除き、残りをメモリに設定する。
7 最初の一つと、メモリのハンドルを返す。

FindCloseは。

1 与えられたメモリハンドルを閉じる。

これで通じたでしょうか？

引用返信 編集キー/

■20209 / inTopicNo.50)

　Re[18]: ディレクトリの排他アクセス

▲▼■

□投稿者/ れい (612回)-(2008/06/07(Sat) 15:32:06)

■No20207 (ちゃっぴさん) に返信
> ■No20191 (ネタ好きさん) に返信
>>「ディレクトリの更新日時が、XXX以前であればXXXに設定する」
>>みたいな作業は、Win32APIでは厳密には出来ないのですね。
>>似たようなことがいろいろとディレクトリではできないのです。

もしかして、私とネタ好きさんは同一人物なのですか？

> 現在だと VSS (Volume Shadow copy Service) 使っとけ！って感じですかね。

はい。
他に手がないわけではないですよね。
しかしShadowCopyはもっといろいろ出来るわけで、
その分技術的に重いので敷居が高い。

FindXXXFileはもったいないと思うんですよね。
無くすわけにはいかないでしょうが。

SetFileInformationByHandleが追加になったように、
CreateFileでディレクトリを普通に開けるようにして欲しいです。

引用返信 編集キー/

■20210 / inTopicNo.51)

　Re[27]: ディレクトリの排他アクセス

▲▼■

□投稿者/ す (21回)-(2008/06/07(Sat) 15:37:40)

■No20208 (れいさん) に返信

file search handle だと不合理で、
directory handle だと合理的だというのは、なぜですか？

引用返信 編集キー/

■20211 / inTopicNo.52)

　Re[25]: ディレクトリの排他アクセス

▲▼■

□投稿者/ す (22回)-(2008/06/07(Sat) 15:44:06)

2008/06/07(Sat) 16:46:48 編集(投稿者)
2008/06/07(Sat) 16:24:15 編集(投稿者)
2008/06/07(Sat) 16:06:34 編集(投稿者)

■No20205 (れいさん) に返信
>>だから、どういう状況でどういうトラブルが生じるのですか？
>
> 最終更新日時二つのディリレクトリを同期したい場合に、
> ソースディレクトリD1の更新日時Aと
> ターゲットディレクトリD2の更新日時Bを比較して、
> ソースの方が新しいならファイルをコピーして…、
> で、最後にターゲットの更新日時をソースの更新日時Aにするわけですが、
> 書いてる間に誰かがD2に対して何か作業するかもしれません。

かもしれません。までは分かりましたが、
だから、そこでどういうトラブルが生じるのですか？

そこから突然、「の二つが必要になります。」と飛躍されても。。。

追伸

わかりました。
「書いてる間に誰かがD2に対して何か作業」して更新日時を新しくしたのに
「最後にターゲットの更新日時をソースの更新日時Aにする」ので戻されちゃったってことですね。

追伸２

「ディレクトリ」でなく「ディレクトリエントリ」に対して、アトミックに
参照更新したいということですね？

追伸３

もし、
ディレクトリエントリに対する排他アクセス機能がWin32APIになぜないのか？
という疑問なら、MS自身が特に必要としてなかったからでしょう。

引用返信 編集キー/

■20212 / inTopicNo.53)

　Re[28]: ディレクトリの排他アクセス

▲▼■

□投稿者/ れい (613回)-(2008/06/07(Sat) 15:46:52)

■No20210 (すさん) に返信
> ■No20208 (れいさん) に返信
>
> file search handle だと不合理で、
> directory handle だと合理的だというのは、なぜですか？

私の投稿は長くて申し訳ないですが、最初から書いてます。
読んでください。

FindFirstFile
FindNextFile
FindClose
の3つを実装する手法と、

例えば、「FindDirectoryEntry」という関数一つを実装し、
CreateFile
FindDirectoryEntry
Close
の順で呼ぶような実装にする手法と、

二つの手のどちらかを選べといわれたら、私は後者を選びます。

また、そもそもファイルシステムは後者で実装されてますので、
前者の実装を思いつかないでしょう。

なのに、Win32は前者になっている。

なので、私の考えた至らないか、なにか特別なポリシーがあったと考えたわけです。

#そろそろ会話が噛み合うかと思うんですが…、どうでしょう？！

引用返信 編集キー/

■20213 / inTopicNo.54)

　Re[25]: ディレクトリの排他アクセス

▲▼■

□投稿者/ 渋木宏明(ひどり) (774回)-(2008/06/07(Sat) 15:49:17)

# 同じところでグルグル回ってるね。

> 必要性がないでは理由になりません。

そんなことはないと思いますよ。
商業ＯＳであるなら特に、必要性が薄いと判断されれば、実装の優先度はズンドコ下がります。

Win32 おける、ディレクトリエントリの読み出しの API が FindXXXFile() なのは完全に歴史的な経緯でしょう。
DOS, 16bit Windows との互換を重要視して、アプリケーション開発者レベルに公開するべき API として定められたものだと思います。

> なにか積極的理由でディレクトリのハンドルを隠蔽しているのです。

動機づけとしてはむしろ消極的なんじゃないかと。

一般の開発者向けに API が公開されない理由は

・なくて困るアプリケーション開発者の絶対数は大した数ではない
・大抵の場合、代替えの手段がないわけではない
・やるとすると、「再帰的なロックはできないの？」とかのＱＡなどに費やすコストがもったいない

とかとか、まぁそんなとこじゃないでしょうか。

何か１個や２個の確たる理由があるようには思えません。

引用返信 編集キー/

■20214 / inTopicNo.55)

　Re[19]: ディレクトリの排他アクセス

▲▼■

□投稿者/ シャノン (458回)-(2008/06/07(Sat) 15:57:52)

■No20158 (れいさん) に返信
> ■No20150 (シャノンさん) に返信
>>出来ても何が嬉しい訳でもないけれど、そうなっている方が自然だと思う、ってことですかね？
>
> そうです。
> 私個人的にはかなりうれしいですが。

この「そうです」は質問の後半部分への返答ですね。
前半部分には「いいえ」と返ってくるわけですね。

> ユーザーが利用できるWindowsのファイルアクセス制御は2種類あります。
>
> 一つは、LockFile関数などで設定できる「Byte Range Lock」です。
> よくわかりませんが、ロックと言うとこれを指す人も多いのかも知れません。
> これは、プロセス毎のロックです。
> (duplicateされた)同じハンドルを使ってもプロセスが異なればアクセスできません。
> 同じプロセスであればハンドルが違ってもアクセスできます。
> これは、ストリームの領域を指定してロックしますので、ディレクトリでは定義されません。

はい。
ディレクトリでは定義できませんから、最初からその話は眼中にありませんでした。
誰かがその話をしていましたか？

>>ロックで、整合性以外に思い浮かぶものがないんですけど。。。
>
> ディレクトリ内の整合性を私は問題にしていません。
> それはまぁ違う技術が解決してくれるでしょう。
>
> 私はAPIの設計理念に疑問をもっていたのです。
> なんでこんな実装になっているの、と。
> こっちのほうがいいんじゃないの、と。

ここを消化するのにちょっと戸惑いました。
ディレクトリ内の整合性をとれなくてもよいと言っているわけではないですよね。
TxFなりVSSなり、整合性を取る技術は既にあるので、ハンドルで扱えないと整合性が取れないから困るというわけではない。
ただ、ハンドルで扱えて、その機構で整合性も取れるほうが自然である。
どうしてそうなっていないのか？
ということで間違いないですか？

引用返信 編集キー/

■20215 / inTopicNo.56)

　Re[22]: ディレクトリの排他アクセス

▲▼■

□投稿者/ シャノン (459回)-(2008/06/07(Sat) 15:59:07)

■No20195 (すさん) に返信
> あるアプリがディレクトリを開いていると、
> 別のアプリが処理を終えてファイルを削除しようするとエラーになる。
> これは悪夢だ。

ファイルを削除するにもディレクトリのハンドルを要するようにすればいいんじゃないですかね。
DBMSよりもずっと、デッドロックに気を使う必要がありそうですけど。

引用返信 編集キー/

■20217 / inTopicNo.57)

　Re[20]: ディレクトリの排他アクセス

▲▼■

□投稿者/ れい (614回)-(2008/06/07(Sat) 16:17:11)

2008/06/07(Sat) 16:18:39 編集(投稿者)

■No20213 (渋木宏明(ひどり) さん) に返信
> # 同じところでグルグル回ってるね。

はい。
なかなか皆に理解できるように説明するのが難しくて。
#とくにすさんには申し訳ないです。

>>必要性がないでは理由になりません。
>
> そんなことはないと思いますよ。
> 商業ＯＳであるなら特に、必要性が薄いと判断されれば、実装の優先度はズンドコ下がります。

ただの言葉の定義の問題かと。

実装優先度の話であれば、
「優先する事項に開発力を回す必要があった」という必要性があります。

歴史的事情であれば、
当時は当時なりの必要性があり、
現在ではそれを変更するコストに見合わない、という必要性があります。

「別に要らないから」という理由とは違います。

全てを考慮すれば「消極的理由」は存在しません。
あるとすれば「偶然」だけです。
で、私はどんな理由でもいいので、必要性をでっち上げて欲しいわけです。

> Win32 おける、ディレクトリエントリの読み出しの API が FindXXXFile() なのは完全に歴史的な経緯でしょう。
> DOS, 16bit Windows との互換を重要視して、アプリケーション開発者レベルに公開するべき API として定められたものだと思います。

ええ。
私もそれで納得しました。

>>なにか積極的理由でディレクトリのハンドルを隠蔽しているのです。
> 動機づけとしてはむしろ消極的なんじゃないかと。

気持ち的に消極的かもしれませんが…。
述べられている理由は私には「積極的」です。

> 一般の開発者向けに API が公開されない理由は
>
> ・なくて困るアプリケーション開発者の絶対数は大した数ではない
> ・大抵の場合、代替えの手段がないわけではない
> ・やるとすると、「再帰的なロックはできないの？」とかのＱＡなどに費やすコストがもったいない
>
> とかとか、まぁそんなとこじゃないでしょうか。

QAのコスト…
つまり開発者を混乱させてしまうコストですね？
なるほど。
MSほどになればそんなのも考えないといけないですよね。

■No20214 (シャノンさん) に返信
>>そうです。
>>私個人的にはかなりうれしいですが。
>
> この「そうです」は質問の後半部分への返答ですね。
> 前半部分には「いいえ」と返ってくるわけですね。

たまたま今やってる作業では喉から手がでるほど欲しいですが、
それが一般的だとは思えない作業なので…。

前半部分も、一般的には「はい」です。

> ディレクトリでは定義できませんから、最初からその話は眼中にありませんでした。
> 誰かがその話をしていましたか？

わたしはすさんがその話と混同してる可能性があると思いました。
違うかしら？

ということは、シャノンさんには私の説明で「共有アクセス制御」のことだと通じてたということですね。
よかった。

> ここを消化するのにちょっと戸惑いました。
> ディレクトリ内の整合性をとれなくてもよいと言っているわけではないですよね。
> TxFなりVSSなり、整合性を取る技術は既にあるので、ハンドルで扱えないと整合性が取れないから困るというわけではない。
> ただ、ハンドルで扱えて、その機構で整合性も取れるほうが自然である。
> どうしてそうなっていないのか？
> ということで間違いないですか？

Yes!
もちろんTxFやVSSほど強力ではないですが、
ディレクトリハンドルという方法で、少しは整合性を確保できると思います。

引用返信 編集キー/

■20220 / inTopicNo.58)

　Re[21]: ディレクトリの排他アクセス

▲▼■

□投稿者/ ネタ好き (383回)-(2008/06/07(Sat) 16:46:22)

2008/06/07(Sat) 16:48:14 編集(投稿者)

私の感覚としてはファイルシステムは階層型データベースで、自分でOSを作る際にはリレーショナルデータベースにしたいと何年もずっと思っていたので、ディレクトリがそのように公開されていないのは、「階層型データベース」だからのような気がします。
階層型データベースは仕組みが分かっていれば効率的なのですが、そうで無い場合は非効率的かつ危険になってしまいます。
とくにロック作業は構造を熟知しないと危険です。
だから秘密主義のマイクロソフトは公開して上手く操作してもらう事よりも「隠して使わせない」戦略をとった気がします。
れいさんは考えはどちらかというとUNIX的で「仕組みを積極的に使用させる」という方針だと思いますが、マイクロソフトはきっと「絶対必要で無い限り隠して使わせない」と考えるのだと思います。
非公開APIがそれを物語っているような気がしてなりません。

引用返信 編集キー/

■20221 / inTopicNo.59)

　Re[26]: ディレクトリの排他アクセス

▲▼■

□投稿者/ れい (616回)-(2008/06/07(Sat) 16:50:42)

■No20211 (すさん) に返信
> そこから突然、「の二つが必要になります。」と飛躍されても。。。

あれれ？
そこが飛躍ですか…。
難しいですね…

他プロセスがターゲットディレクトリにファイルを書いたのを、
「最終更新日時から検出したい」とします。

普通、
自プロセスがターゲットディレクトリD2にファイルを書いても、
他プロセスがターゲットディレクトリD2にファイルを書いても、
ターゲットディレクトリの最終更新日時は変更されます。

自プロセスがターゲットディレクトリD2にファイルを書いても、
D2の最終更新日時が変更されないようにできるならば、
D2の最終更新日時を見れば、他プロセスが書き込んだか検出できます。

同様に。
D2の最終更新日時Aをまず取得し、
D2にファイルを書き込み、
D2の最終更新日時Bを取得して、それがファイルを書き込んだ日時と同じであればAにもどす、
という作業を全てのファイルに対して繰り返し、
一回でも日時が一致しなければ他プロセスからアクセスがあったと判定できます。

> 追伸
> 「書いてる間に誰かがD2に対して何か作業」して更新日時を新しくしたのに
> 「最後にターゲットの更新日時をソースの更新日時Aにする」ので戻されちゃったってことですね。

そうです。
戻す前に確認したくても、
確認して、戻す前に変更されてしまうかもしれません。

> 追伸２
>
> 「ディレクトリ」でなく「ディレクトリエントリ」に対して、アトミックに
> 参照更新したいということですね？

？
ちょっと言ってることがわかりません。
ルート以外の全てのディレクトリはディレクトリエントリなので…。

> 追伸３
>
> もし、
> ディレクトリエントリに対する排他アクセス機能がWin32APIになぜないのか？
> という疑問なら、MS自身が特に必要としてなかったからでしょう。

だから…

MSは必要としていたのです。
なので、ファイルシステムではディレクトリへの排他アクセスが必須になっています。
なのに、Win32APIには無いのです。

引用返信 編集キー/

■20222 / inTopicNo.60)

　Re[27]: ディレクトリの排他アクセス

▲　■

□投稿者/ す (23回)-(2008/06/07(Sat) 17:03:17)

■No20221 (れいさん) に返信
>>「ディレクトリ」でなく「ディレクトリエントリ」に対して、アトミックに
>>参照更新したいということですね？
>
> ？
> ちょっと言ってることがわかりません。
> ルート以外の全てのディレクトリはディレクトリエントリなので…。

「ディレクトリ」は「ディレクトリエントリ」の集合体です。
集合体全体にロックをかけるのではなく、１要素にロックをかけるということ。
グラニュールが全然違います。

>>追伸３
>>
>>もし、
>>ディレクトリエントリに対する排他アクセス機能がWin32APIになぜないのか？
>>という疑問なら、MS自身が特に必要としてなかったからでしょう。
>
> だから…
>
> MSは必要としていたのです。
> なので、ファイルシステムではディレクトリへの排他アクセスが必須になっています。
> なのに、Win32APIには無いのです。

だから、
MS自身が「そういうWin32API」を特に必要としてなかったからでしょう。
だから、Win32APIには無いのです。

引用返信 編集キー/

＜前の20件 | 次の20件＞
トピック内ページ移動 / << 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 >>

- Child Tree -