過去の桐井戸端BBS (桐ver.8) |
23434 | Windowsの起動時に桐の共有環境ファイルを自動的に削除するようにしたい | 尾形 | 2003/11/22-09:29 |
よろしくお願いします 自分のシステムが問題が起きて正常に動作しななりました 自分のプログラムに問題があるのでは?と色々調べました よく調べてみるとある表が専有では開くのに 共有参照、共有更新でひらけない状態になってました。 原因がわかれば簡単な事なのですが 表は壊れてないし、原因を調べるのに、時間掛かりました KIRI8.FSC, KIRI8.USR, KIRI8.TXN 結局これらのファイルを削除するだけでよかったのですが なんか馬鹿らしかったです そこで質問なのですが、桐の共有環境設定用のファイル (KIRI8.FSC, KIRI8.USR, KIRI8.TXN)を削除するバッチファイルを作って、 サーバのスタートアップに設定しておこうと思うのですがまずいでしょうか? サーバは退社時には電源落としますので、ファイルは毎日削除される事になのるですが | |||
23439 | Re:共有環境ファイルの削除 | hidetake | 2003/11/22-10:50 |
記事番号23434へのコメント >そこで質問なのですが、桐の共有環境設定用のファイル >(KIRI8.FSC, KIRI8.USR, KIRI8.TXN)を削除するバッチファイル >を作って、サーバのスタートアップに設定しておこうと思うのですが >まずいでしょうか? 誰もアクセスしていない状態だったら(だから)特に問題は無いと思いますが スタートアップというのが,スタートメニューのスタートアップと言う事でしたら, それより,タスクスケジューラの「システム起動時」の方が良いのではありませんか? システムは起動してもログオンして無くて,その間に誰かが桐のシステムを使いだして, その後にサーバにログオンしたとか,サーバで一旦ログオフした後にログオンし直した時の事を考えると・・・ あと,桐の共有管理情報の動きを桐9 ではあまり見ていなかったので,もう1度調べてみました。 どのファイルが開かれていると言う情報が入っている KIRI8.FSC はネットワーク(桐の)に初めて参加する時に一旦削除されるようです。 これは KIRI8.SEM の存在か共有で開かれている事のチェック,もしくは KIRI8.USRに ログオンユーザが存在するかどうかの何れかをチェックして KIRI8.FSCを削除しているのでしょうか? これに対して,桐ver9 sp1 は初めてネットワークに参加した場合でも KIRI9.FSC は存在しています。 初めは桐8 と違って削除しなくなったのか? と思いましたが,よく調べてみると一旦削除したうえで,即時再作成されるようです。 これは桐9 になって桐の起動時,桐の SYSTEMフォルダにある KIRIFUNC.TBL を必ずウラで開くようになって影響なのか, 他の影響があるのかわかりませんが? と言う事で,KIRIx.FSC の削除はシステムが正常であればネットワークに 初めて参加する桐が本来であれば削除するものと思われますが, そうでなく異常が残っていると何らかの影響を及ぼすのかも知れません。 例えば,異常終了などで KIRIx.USR に幽霊が残ってしまう場合とか? これについては一応 #使用者数 で調べる事も可能です。桐8 の初期の頃は 私の環境でも幽霊が増え続ける現象が何度も起こった事があります。 | |||
23442 | Re:共有環境ファイルの削除 | 尾形 | 2003/11/22-13:12 |
記事番号23439へのコメント どうも、ありがとうございます >タスクスケジューラの「システム起動時」の方が良いの >ではありませんか? なるほど、そうですね! 早速そうします | |||
23574 | Re:共有環境ファイルの削除 | hidetake | 2003/11/29-07:16 |
記事番号23442へのコメント >>タスクスケジューラの「システム起動時」の方が良いの >>ではありませんか? ちょっと補足です。 (^^; タスクスケジューラの「システム起動時」以外にも Windows2000 以降であれば, 「グループポリシー」から追加できる「スタートアップ スクリプト」 と言うのもあったのですね! 今まで知りませんでした。 (^^; もし尾形さんが最初からこの事を言われていたのなら, そちらの方が良いかも知れません。タスクスケジューラの「システム起動時」より 「スタートアップ スクリプト」の方が先に実行されるようです。 ただ,タスクスケジューラの「システム起動時」の方に登録したスクリプトは非同期的に実行され, システム的にも次のステップが次々と実行されていくようですが, グループポリシーの「スタートアップ スクリプト」の方は非同期的に実行されるようで, そのスクリプトが実行完了しないとWindows のシステム自体もそこで待機しているようです。 私がタスクスケジューラの「システム起動時」で登録して使っているものを タスクスケジューラサービスを停止できるのならばと,「スタートアップスクリプト」の方に移して 試してみたところ,ずーと(3分ほど)そこの場面でスクリプトが実行終了するのを待っていました。 (;_;) 実は私のパソコンが起動する時に,他のパソコンも自動的に起動させるスクリプトを組んで, 他のパソコンが立ち上がったと思える時間までsleep で待機させ, 他のパソコンのドライブを MAP するスクリプトなのでした。 サーバの場合は「タスクスケジューラ サービス」を使用している場合が ほとんどだから構わないでしょうけど,クライアントパソコンの場合, もし「タスクスケジューラ サービス」を使っていなくて, 少しでも無駄なサービスを停止したい(停止できる)ならば,この方式の方が有効かなと思ったしだいです。 (^^; 参考サイト Windows 起動時に読み込むサービスの順序を制御したい http://www.monyo.com/technical/windows/33.html |