過去の桐井戸端ＢＢＳ　（桐ver.８）
13080 桐はWindows2000/NTで共有するとヤバイのでは！？ 島尾 2001/09/18-10:19
以前、共有管理ファイルがロックされたまま解放されないという話題があがりました。
↓
http://www.fuku3.com/~habata/kbbs/kakov8/12193.htm

その話題の続きなのですが、
いろいろ調べた結果、Windows2000/NTをファイルサーバーとして
そこに共有情報管理ファイルを置いてある場合は、NTFS/FATに関わらず、
参照ツリーの話題のように、同じ共有情報管理ファイルを持つユーザーがＰＣの強制終了をしたりすると、
他のユーザが桐を起動すら出来なくなる現象が出てきます。

また、他のユーザーが誰も開いていないのに「他のユーザーが使用中」の表示がでてロックしてしまう場合もあります。
また、、Windows2000/NTのドライブに共有情報管理ファイルを設定してある場合は、
Windows98/MEなどに共有情報管理ファイルを設定してある場合に比べ、
二本目移行の桐の起動がかなり遅くなってしまいます。
（テスト結果、98/meの場合は約2.5秒、2000/NTの場合は８秒）
しかも、この問題の根本的な対策方法は何もありません。
上記のような症状が出るたびに、サーバーへ駈け込んで強制解放などをする必要があります。

このような状態が現在の桐８SP6の「仕様」になっているのでは、
桐はWindowsNT対応とは言えないのではないでしょうか？
少なくとも「共有」での使用では問題点あり、と正式に言えるような状態ではないですか？
これが原因のエラーの対応ばかりで非常に困っております。
それともなにか「根本的」な解決方法があるのでしょうか？
13083 Re:桐はWindows2000/NTで共有するとヤバイのでは！？ pokopon 2001/09/18-11:34
記事番号13080へのコメント
島尾さん　こんにちは

>以前、共有管理ファイルがロックされたまま解放されない
>という話題があがりました。↓
>また、、Windows2000/NTのドライブに共有情報管理ファイルを設
>定してある場合は、Windows98/MEなどに共有情報管理ファイルを
>設定してある場合に比べ、二本目移行の桐の起動がかなり遅くな
>ってしまいます。
>（テスト結果、98/meの場合は約2.5秒、2000/NTの場合は８秒）
>このような状態が現在の桐８SP6の「仕様」になっているのでは、
>桐はWindowsNT対応とは言えないのではないでしょうか？

前回も情報を提供いたしましたが、私のところの環境においては、あれ以来安定してきました。
１．怪しいパソコンは、できるだけチューンナップしました（OSの入れ替え）
２．サーバーのＤＮＳ設定、ＤＨＣＰ環境の設定、ゲートウエイ等の設定を改善しました。
クライアント側も、ネットワークの設定をサーバーから全て拾うようにし、
機器間での設定の差がないようにしました。
機種の更新の際には、できるだけスペックの高い機器に変更しました。

などと、ネットワークの改善を試みた結果、安定化が図られました。
フリーズ機器は迷わずＯＳのみのクリーンインストールに切り替え、Win9X系ならば
「Win98SE」へ変更しております。

などなど、細かなクライアントの設定のおかげ（かどうかは？？）で、フリーズ機器の発生は最小限となり、
例の「ギロチン処刑」は少なくなりました。
現在では安定して稼動しています。よっぽどのこと（ユーザー側の不注意）がなければ、「桐が起動しない」という現象は起きていません。

これまでの様子から、
WinMeはやっぱり不安定です。
ワードとともに使い、なおかつ桐も立ち上げる・・・・、「これだけはやめてくれ」と職員に連絡しています。
Winそのものが不安定なのは前からですが、使って見ての感想として、クライアントのＯＳとして、Win98SE Win2K なら、安定使用可能です。
ですので、「桐がネットワーク環境では使えない」とまでは思ってはおりません。

なお、「Win2Kで桐の起動が遅い」ということはありません。８秒とは・・・・。
もしかして、常駐型のウイルスチェッカーを使っていませんか？
例えばMcAfeeが常駐していれば、桐の起動が遅くなることはあります。
はずして見て下さい。当方ではＯＳによる桐の起動には大差がありません。

13084 何でなんだろう。もう泣きたいです。 島尾 2001/09/18-13:44
記事番号13083へのコメント
情報ありがとうございます。
どうもエラーの原因は大半がユーザー側の不注意なのです。
（強制的にパソコンを終了してしまう場合がある。）
また桐だけのパソコンではないので、どうしても他のソフトと併用して起動してしまいます。
使う人間もＰＣを余り知らない人が大半なので、とにかく操作の決まりを徹底するのがムズカシイ状況です。
「そんな環境で桐なんて使うな！」と言われれば、それまでですけど・・・
win98系のファイルサーバーならば、共有管理情報ファイルが永遠に専有される事もなく、
起動も早いので、ただこれと同じ状態にNT系ファイルサーバーでもなってくれればいいだけなのです。
常駐型のウィルスチェッカーは入れてありますが、外しても起動時間に大差はありませんでした。
本当に不思議なのは、なぜNT系のファイルサーバーに共有管理ファイルがあるというだけで、起動に８秒もかかってしまうのか？
98系のPCに共有管理ファイルがあると２秒程度で起動できるのに、です。

なるべくスペックの早いＰＣにするとか、ネットワークを100BASEにするとか、
出来る限りの対応は行ったのですが、やはり突然、桐が起動できなくなる事がしばしばあります。
もう本当に、桐ってNTをＦサーバーにできるの！！
って疑いたくなった訳なんですが、やっぱりこっちの設定がどっか悪いのでしょうね。
念のため、誤解があるといけないので書きますが、WIN2000の桐の起動が遅いのでは無く、
Win2000のPCに共有管理情報ファイルが指定されている全ての桐（NT,2000,98,ME問わず）が遅くなります。
この問題さえ解決できれば、データが壊れることも無いし、かなり安定動作なのですが、
こればかりは人が居ないと元に戻せないので非常に苦しいです。
いっそWin98をファイルサーバ代わりにしてそこで共有したほうが、とも考えていますが、
今度はOSとして24時間稼働に耐えられるか、という問題もありますし。うーん、、困った。
13085 Re:何でなんだろう。もう泣きたいです。 hidetake 2001/09/18-14:04
記事番号13084へのコメント
データは NT においたときもそうなのですか？
Windows2000 Server の場合、設定によっては

「Active Directoryをインストールする際、
ディスクキャッシュが無効になる」
http://www.novell.co.jp/advantage/w2k/w2k_dyk1.html

なんて事もあるようです。これが関係するかどうかわかりません・・・
それから、Windows2000 の場合は裏でいろいろやっているようですので、
チューニング部分も多いようですが、何か隠れた部分が影響しているのかも知れませんね？

スワップなどもオートでは追いつかない場合も
あるようですし・・・　:-)


13086 Re:何でなんだろう。もう泣きたいです。 pokopon 2001/09/18-15:05
記事番号13084へのコメント
島尾さん こんちちは

>どうもエラーの原因は大半がユーザー側の不注意なのです。
>（強制的にパソコンを終了してしまう場合がある。）
そのとおりです。これを最小限に防ぐ手立てをして見て下さい。

>win98系のファイルサーバーならば、共有管理情報ファイルが永遠に専有され
>る事もなく、起動も早いので、ただこれと同じ状態にNT系ファイルサーバー
>でもなってくれればいいだけなのです。
>常駐型のウィルスチェッカーは入れてありますが、外しても起動時間に大差
>はありませんでした。
>本当に不思議なのは、なぜNT系のファイルサーバーに共有管理ファイルがあ
>るというだけで、起動に８秒もかかってしまうのか？

ＮＴＦＳですよね。こちらはなんともないですよ。
データも共有情報用のフォルダも、全てサーバーにあります。
Win2Kに限らず、Win9X系でも、起動の早さには差はありません。
何かしら共有ファイルがあれば、全体に遅くなりますが、８秒？？？
これは遅すぎます。

>98系のPCに共有管理ファイルがあると２秒程度で起動できるのに、です。
>なるべくスペックの早いＰＣにするとか、ネットワークを100BASEにすると
>か、出来る限りの対応は行ったのですが、やはり突然、桐が起動できなくな
>る事がしばしばあります。もう本当に、桐ってNTをＦサーバーにできるの！！
>って疑いたくなった訳なんですが、やっぱりこっちの設定がどっか悪いので
>しょうね。

サーバーの設定がかなり影響していることは確かです。どのようなサービスが動いているか、
再度確認してみてはどうでしょうか？
ちなみに、こちらで影響があった設定として、
クライアントのネットワーク設定をＤＨＣＰで拾う場合に、ＤＮＳの設定が大事でした。
クライアントが一発でＤＮＳ（サーバーを）を探せるように、ＤＨＣＰで指定、
あるいはＤＨＣＰを使っていない場合には、クライアント側の設定をしっかりしておくことが大事かと思います。
ＧＷも。

ちなみに、ＬＯＧＯＮスクリプトで最初に「共有フォルダ用」のドライブマップを完了しているのですよね。
ＬＯＧＯＮするたびに、きちんとドライブがクライアント側に設定されていることが大事かと思います
（クライアントの設定をどのようにしてますか？）

もうひとつはＩＩＳでした。インターネット接続の際にＩＩＳを設置しましたが、
このチューンナップが結構影響したような？？？（うらおぼえですけど）。
ＩＩＳは結構重いサービスです。以前は必要なかったので、削除したくらいです。
サーバーにメモリ投入で何とか我慢できるスペックになりましたので、
ＷＥＢプロキシのためにＩＩＳを再度入れました。

それと、
Ｋ３にも問い合わせして見る手もあります（何か情報をくれって）。

余りお役に立たなくてすいません。


13089 Re:何でなんだろう。もう泣きたいです。 hidetake 2001/09/18-17:46
記事番号13085へのコメント
あと、島尾さんのところと逆の現象ですが、Windows98 から
Windows2000 を見る場合に較べて、Winodws2000 から Windows98の
共有を見る場合は時間がかかる事があります。

http://homepage2.nifty.com/winfaq/w2k/network.html#1173
http://homepage2.nifty.com/winfaq/w2k/network.html#988

この他にもオフライン機能とか Windows2000 にはなにがしら
便利な側面と遅くなりそうな側面もいろいろ持っているので
チューンナップすべきところも、こちらのサイトには書いてあります。


あと取り残されたファイルの解放など、別にサーバに行かなくても
リモート管理が許可されていれば、コンピュータの管理で
「別のコンピュータへ接続」でサーバに接続して対処する事も可能ですよね・・・
あるいはターミナルサービスも結構面白いし、リモートメンテも簡単ですし！


13100 アドバイスどうも。結局まだ改善できません 島尾 2001/09/19-08:35
記事番号13080へのコメント
どうもありがとうございます。
いろいろなアドバイス通り試してみました。
しかし結局、起動に８秒もかかるのは改善されず、
メインのサーバーとは別途に、バックアップドメインサーバーを新たに
Windows2000を実験的に構築し、そこのHDDを共有管理情報ファイルに指
定しても、状況は改善せず。HDDをFAT32やFAT16にしても改善せず。
簡単な判別方法として、一台のPCの桐の共有管理情報を自分のローカルHDDに指定して、桐を複数起動します。
１個目は即起動。２個目は２秒程度で起動。
こんどは共有管理情報をWindows98の他のコンピュータにしてみても、同様。
しかし、共有管理情報をWindows2000のPCにすると、１個目は即起動。
２個目は８秒程度かかります。
何かがおかしいはずなのですが、別途構築したWindows2000でも同様の現象が起こるというのは、いったい？？
共有管理情報のあるフォルダ名やボリュームラベル名が日本語だとダメなのか？
と思い英語に変えてもだめ。
NetBiosの性なのかとおもい、TCP/IPオンリーの環境にしてみてもダメ、
クライアントの設定はDHCPで設定されるようにしてあるし。
引き続き調査してみます。
13103 Re:アドバイスどうも。結局まだ改善できません hidetake 2001/09/19-10:37
記事番号13100へのコメント
>しかし、共有管理情報をWindows2000のPCにすると、１個目は即起動。２個目
>は８秒程度かかります。

少々実験してみました。

Windows2000 Professorial に共有管理情報を設定すると
確かに２個目からの桐の起動に時間がかかるようです。
それから Windows2000 Server と Windows4.0 Server で
も同じようです。

Windows98 に共有管理情報を置いた場合は２個目の桐の
起動でもさして時間はかからないようです。
それから、Linux + Samba (TurboLinux Server 6.1) と
NetWare 5.0 SP6a に共有管理情報を置いた場合も時間的に遅くなる事は無いようです。

あと興味深かったのが、Windows2000 Professorial に
共有管理情報を設定した時、その Windows2000 Professorial自身から桐を起動する場合なのですが、
共有管理情報をUNC で記述すると、他のクライアントパソコン同様、
桐の起動が遅くなるのですが、ローカルドライブ名で記述すると、
いつものように素早く起動する事です。
共有管理情報を置かない他のクライアントパソコンでは
UNC で記述しようとマップしたドライブ名で指定しよう
と起動時間は変わらないようです。

コンピュータの管理で見てみると、共有管理情報を UNCで記述した場合と、
ローカルドライブで記述した場合の違いがわかりますが、ローカルドライブで設定した場合は、
共有の開いているファイルに表示されませんが、
UNC で記述すると、開いているファイルに出てきます。

ちなみに、この共有管理情報を置いた Windows2000 Professorialだけで
桐を複数個起動しても時間が長くなる問題は生じない無いようです。

何か WindowsNT/2000 系列では UNC 系の処理やネット経由の処理で、
桐が使う部分でも特別な事をやっているのでしょうか？

起動時の数秒の話なので遅いパソコンでは良くわからないし (^^;
その後の使用上で何か問題があるのかもわかりませんが、あとは K3 の見解でも聞いてみる！
でもされたらいかがでしょう？

ps.
桐のクライアント台数が相当多い場合ですが、桐はファイルパレットや開くの処理で表題や更新日付や更新日付
を表示しますが、この情報も桐はファイルの中に持っているデータを取りだし表示します。
と言う事は、この処理でもファイル共有の処理を行っているはず？です。
一つのフォルダにとても多くのファイルを置いていたり、
ファイルパレットを頻繁に表示するようになっていると
この辺の処理も負荷になるのでしょうか・・・


13132 Re:アドバイスどうも。結局まだ改善できません 島尾 2001/09/20-09:57
記事番号13103へのコメント
調査ありがとうございます。
やはり仕様？バグ？だったのでしょうか？
ファイルサーバーはWindows2000serverです。
あと別の実験として、秀丸エディタというエディタソフトで、
他のユーザが開いているファイル（上書き禁止状態）のファイルを開くと
「上書き禁止です」みたいな警告がファイルを開くと同時に表示されるのですが、
桐の共有情報管理ファイルのkiri8.SEMを桐を起動して、
次に秀丸でオープンすると、その警告が表示されるまで２秒程度のタイムラグがあるのです。
ところが、Windows98系のファイルサーバーに置いた場合は、秀丸でもそのタイムラグは無く、瞬間的に表示されます。
もしかして、これは桐だけの問題ではないのかも？　といった疑問が出てきました。
LinuxなどではOKだそうなので、こちらで代行できないかなど、また色々ためしてみます。


13133 Re:アドバイスどうも。結局まだ改善できません hidetake 2001/09/20-10:24
記事番号13132へのコメント
>LinuxなどではOKだそうなので、こちらで代行できないかなど、また
>色々ためしてみます。

Samba には Samba の問題(特徴)や癖、
それにスピードの問題やらいろいろ
あります。(^^;
まぁ〜、いろいろ試してみて下さい！


13137 結局ダメそうです 島尾 2001/09/20-16:23
記事番号13133へのコメント
よく考えたらkiricgi.exeをつかっているので、
リナックスに移行は無理でした。
共有情報管理ファイルだけリナックスに置く、というのは
片方が墜ちたら全体ダウンになってしまうので、リスクが高いし、
やっぱだめかぁぁ(T_T;
Windows2000には困ったもんだ。

戻る