過去の桐井戸端ＢＢＳ　（桐談義・その他）

17651	桐ファイルをＷＩＮ２Ｋに置いて共有していると２台目以降のマシンが遅くなるというのは桐９で解決していますか	しどろ	2002/10/21-13:38
過去の掲示板の中にある、「桐はWindows2000/NTで共有するとヤバイのでは！？」 2001/09/18番号１３０８０での話題について。 　当方でも同じ現象が起きていました。ＷＩＮ２Ｋマシン上に管理情報ファイルや表ファイルを置いて共有していると、 ２台目以降のマシンの起動が遅くなるのです。 　その後、Linux上で共有してみたりいろいろしてみましたが今はWin98で共有しています。 が、このマシンが１週間に１回ぐらいの頻度でいつの間にか固まってしまいます。 　桐９のバージョンアップの案内も来ていますが、 このＷＩＮ２Ｋマシン上で共有する場合の問題は解決していないのでしょうか。 ちなみに、LinuxではOKでした。 しかし、行き当たりばったりでインストールできただけで今後の管理に自信が持てないので、 Win９８に戻してしまいました。
17656	Re:桐ファイルをＷＩＮ２Ｋに置くと	ybb	2002/10/22-07:50
記事番号17651へのコメント はじめまして win2k の sp3 は当てられましたか windowsのファイル共有自体に不具合があるようです 一度お試しになってはいかがでしょう
17658	Re:桐ファイルをＷＩＮ２Ｋに置くと	島尾	2002/10/22-13:34
記事番号17651へのコメント 桐９βでためした限りでは、この問題は解決していないようです。 あと当方ではサーバーにw2kSP3を当てても解決しておりません。
17659	Re:桐ファイルをＷＩＮ２Ｋに置くと	しどろ	2002/10/22-16:13
記事番号17651へのコメント ybbさん、そして１３０８０の親スレッドの島尾さんご回答ありがとうございます。 　ホントのとこ、過去掲示板で「Windows2000には困ったもんだ。」で終わられた島尾さんに 現状はどうしていらっしゃるかお尋ねしたいと思ったのでした。 　現在もＷｉｎ９８ＳＥで共有されているのでしょうか？ 　また、もしこの現象が他の方では起きていないならば島尾さんの桐とビルド番号などが共通しているのでしょうか？ 当方の桐は「桐 ver8 sp6 ビルド番号#191」です。 お答えお待ちしています。
17674	Re:桐ファイルをＷＩＮ２Ｋに置くと	島尾	2002/10/23-08:47
記事番号17659へのコメント ビルド番号は同じく#191です。 全く新規にサーバーを立ち上げても２個目以上の桐が起動が遅い現象に見舞われています。 （共有管理情報がW2kの場合）結局Win2Kで我慢して使っている状態です。 他の方はこの現象がおきないのでしょうかね？それとも共有をW2Kで使う人が居ないのか？？？ 桐９βでもなったので、ＯＳレベルな話ではないかと疑っています。 近日中には桐９正式版が届くと思うので、時間があったら試してみます。
17677	Re:桐ファイルをＷＩＮ２Ｋに置くと	hidetake	2002/10/23-11:43
記事番号17674へのコメント 島尾さんが前に書いておられるのですが，共有管理情報の中にはKIRI8.SEM と言うファイルがあり， これは一番最初に桐を開いた人がファイルを作成し， そして後はリードオンリーモードで桐が起動している間，ずぅ〜っと開きっぱなしになっています． そして，後から起動された他の桐もリードオンリーモードで開くことになります． そして，このファイルが削除されるのは，一番最後に桐を閉じた人になります． このファイルは，桐がハングアップした場合に残ったままになりますが， 特に残っていても問題になるような事は無かったと思います． そこで，桐を開いた後でこのファイルを開いているセッションを強制終了し， このファイルを強制削除して見ました． 特にその後KIRI8.SEM を削除された桐も動作上は問題が生じる事も無かったようですが， 詳しくいろんな作業を行い調べたわけでは無いので， 本当に何も問題が無いかまで確認された状態であるわけではありません． で，その状態で，別の PC から，２つ目の桐を起動したら， 起動は，通常の２つ目の桐の起動のように数秒(6〜7秒)掛かる事もなく，わりと瞬時に開くようです． この桐の２つ目以上の起動にホンの少しですが， 数秒を要してしまうと言うのは KIRI8.SEM が影響しているように思います． それで，先の条件も顧慮し，KIRI8.SEM に「読み取り専用」属性と「隠しファイル」属性を付加し試してみました． この状態ですと２つ目の桐の起動にも，それほど時間を要さず起動できるようです． なお実験の結果，ファイル属性は「読み取り専用」属性だけでも， 「隠しファイル」属性だけでも，どちらか一方が付加されていれば同じ結果のようです． もちろんこの状態では，桐が１つも起動していない状態でも， (最後の桐が終了する段階でも) KIRI8.SEM が削除されずに残っている状態になります． KIRI8.SEM に「読み取り専用」属性などがついている事によって 無駄なファイルの(状態の)チェックや，リトライを繰り返したりせずに 起動時間が異なって来るのでしょうか？？？ まぁ〜，問題と言っても起動時のホンの数秒の問題なのかも知れませんが， この問題を解決しようとしたら，共有管理情報の仕組みや KIRI8.SEM の取り扱いに対策を行えば良いのかな？ で，KIRI8.SEM って一体何の為に存在しているのでしょうかねぇ〜？ 最後に KIRI8.SEM の属性を変える事により，何が起こるのかまでは細かくチェックしたりおりませんでの， 実験も自分のリスクで行って下さい．
17679	Re:桐ファイルをＷＩＮ２Ｋに置くと	hidetake	2002/10/23-12:48
記事番号17677へのコメント >で，KIRI8.SEM って一体何の為に存在しているのでしょうかねぇ〜？ これはどうも，ネットワークに接続しているユーザが実際に生きているかどうかをチェックしているファイルのようです． すなわち，共有管理情報の場所に KIRI8.SEM そのものが存在していない場合は，他に共有者がいない！ もしこのような状態で KIRI8.USR や KIRI8.TXN 等の 共有ファイルが存在し，中に共有情報が残ったままであったら， その情報は過去のものであり，生きた情報では無いものとして情報を破棄する？ もし，存在していたとしても，ハングアップやネットワークの切断等で 実際に生きて接続されているユーザが存在しているとは限らない． 従って，このファイルを操作してファイルが削除できたり新規に作成できたりするか調べ， もしそのような事が可能ならば，既存のKIRI8.SEM は既に死んだユーザが使っていたものとし判断し， 共有情報をクリアするとともに KIRI8.SEM を新規に作り直すか更新を行う！ もし，既存の KIRI8.SEM が操作できないファイルならば生きているユーザが 存在しているので共有管理情報も生きた情報として処理する． と言った具合のようです．（本当か？） 以上は，１つめの桐を起動した状態で KIRI8.SEM を削除し， 次に別の桐を起動して KIRI8.SEM の作成の状況やその他の共有管理情報ファイルの中身， それと#使用者数から判断し，勝手に想像した内容です． 従って，もしハングアップ等による幽霊などが無くて 完全にその他の共有管理情報が正しければ，ファイル属性の変更で 直接的な影響は出てこないかも知れないですけど， そうで無い場合，共有管理情報の整合性が崩れ (回復できずに)問題が生ずる場合もあるかと思います． と言う事で，単純に属性を変更してしまうと開発者の 意図した通りには動かなくなってしまうようです．
17687	Re:桐ファイルをＷＩＮ２Ｋに置くと	hidetake	2002/10/23-15:57
記事番号17679へのコメント ついでに書いておくと・・・ 桐は起動時，共有管理情報の場所に s で始まり， 最小2文字，最大4文字の長さ 0 のファイルを作成して削除も行っているようです． さて，一体何のために使用されるファイルでしょうか？ 書き込み可能かのチェック？でしょうか・・・ それから，KIRI8.SEM が更新可能な状態では KIRI8.SEMや， KIRI8.USR に KIRI8.FSC 等は，そのファイルそのものを更新するわけでは無く， 一旦削除した後に，新規にファイルを作り直しているようです． ２つ目の桐の起動時は KIRI8.SEM がリードオンリーで開かれているので， 他の PC も更新はできないし 削除や新規作成も不可能！　で，その辺のチェック？ (無理やり削除してみたり読み書きを試みたり？)に W2K系列では時間かかる処理を桐は行っているのでしょうか？ リードオンリー属性を付けていると最初から更新で きないのは把握できるので，無駄な努力はしない？ のかも知れません． 桐の共有って，共有自体が難がある仕組みですし， パフォーマンスも得られない！(得にくい？)と思うのですが， 起動時の多少の時間だけで，ここの部分だけを弄るのもどんなものでしょうか？ この問題だけだったら多少の仕組みの変更で改善は できるかも知れないけど，もっと！もっと！根本的な部分を直して欲しいところだと思います． でも，そうなるとファイル構造やエンジンまで大がかりな改造を行わないと済まないはず！ だと私は思います． だから桐9で，時間は多少掛かっても良いので手を付けてもらいたかったところではあります．　(;_;)
17692	Re:桐ファイルをＷＩＮ２Ｋに置くと	島尾	2002/10/23-17:10
記事番号17687へのコメント 調査ありがとうございます。 KIRI8.SEMに書き込み禁止属性か、隠し属性をつけると確かに起動が速いままになりました。 ＞無理やり削除してみたり読み書きを試みたり おそらくこの処理がW2kでは遅いのが原因のようですね。 なにかOSレベルで解決できる手段があればいいのですけど。
17693	Re:桐ファイルをＷＩＮ２Ｋに置くと	島尾	2002/10/23-17:22
記事番号17692へのコメント 桐を起動する前にKIRI8.SEMをチェックして、共有状態なら属性を 書き込み禁止にして桐本体を起動し、起動完了後に属性をもどす、 共有状態じゃないなら、共有情報ファイルを全削除してから 桐本体を起動、みたいな起動補助プログラムを作成すれば切り抜けられそうですね。
17694	Re:桐ファイルをＷＩＮ２Ｋに置くと	hidetake	2002/10/23-17:23
記事番号17692へのコメント >おそらくこの処理がW2kでは遅いのが原因のようですね。 >なにかOSレベルで解決できる手段があればいいのですけど。 桐が無理やり何をやっているのかがわからないので OS 側でどの部分が問題になっているのかもわからない状態です． だから弄るべき部分も不明な状態！ あと，初期の桐(SP)では桐がハングアップなどしても， 幽霊のユーザが残ったままになり，#使用者数もそのままで， 実際の接続数より多い事になってしまうと言う不具合？がありました． それで，この辺の改善を K3 に依頼した事はありましたが， その改善の１つとして，KIRI8.SEM が更新できるかどうかで， 実際のユーザがいるかを判断し，存在していない場合は KIRI8.USR 等を 初期化するという機能が付け加えられたのかも知れません． ですので，桐8 の SP1 等ではどんな状況になるのかというのも 気に掛かる部分ではあります． タブン K3 がまともに対処しないとユーザでは解決できる問題では無いと思います． ただ，ハングアップ時などの対処をユーザ側で対処できれば， ファイル属性の変更で誤魔化して使う事もできるかも？とか・・・　:-)
17817	Re:桐ファイルをＷＩＮ２Ｋに置くと	しどろ	2002/10/31-15:25
記事番号17694へのコメント しどろです。 一週間ほど出張に出ていたものでお礼ができずすみません。 皆様には共有管理情報ファイルのしくみなど いろいろ調べていただいてありがとうございました。 わたし的には、Ｋ３がまともに対処してくれるまで待ってます。 すでに、似たような質問が出ているようですね。 これだけ出てくれば「まともな対処」も速いことでしょう。 忘れ去られたスレッドですが、質問者のお礼で終わっておきます。

戻る