none
System.IO.Directory.Existsメソッドが予期しない結果(false)を返す場合の対策方法 RRS feed

  • 質問

  • いつもお世話になっております。

    C#で System.IO.Directory.Exists メソッドを使用してフォルダの存在チェックを実行していますが、対象フォルダが存在している場合でも、予期しない結果(falase)を返す不具合が発生しており、とても困っています。

    その場合の対策方法や回避方法をご存じでしたら、ご教授をお願いいたします。

    なお、知人のしりあいの環境で発生している不具合のため、不具合事象が発生する端末の詳細な情報が確認できない状況で大変恐縮ですが、おそらく以下の状況と思われます。

    OS:Windows 10 Pro ビット不明

    起こっている不具合事象:

     存在チェックしたいフォルダのパス: \\192.168.0.1\share\temp

     実行した処理のイメージ:

      string tempPath;

      tempPath = 上記のフォルダパスを返すメソッド ;

      if (System.IO.Directory.Exists(tempPath) == false) {

       エラーメッセージの表示メソッド ;

      }

     上記の処理を実行した場合に、チェック対象フォルダが存在しても、

     falseが返ってきて、エラーメッセージが表示されてしまいます。

     チェック対象フォルダは、処理を実行する端末とは、

     別の端末上で共有設定されたフォルダです。

     フォルダの共有設定、アクセス権限については、正しく

     設定されていることを確認しています。

     ちなみに、Everyoneでフルコントロールです。

    参考情報:

     (1)原因切り分けのため、上記の処理を1時間程度繰り返し、

        falseが返されていることを確認している状態で、同じ

        端末のコマンドプロンプトから以下のコマンドを

        実行したところ、チェック対象フォルダの内容が

        表示されました。(コマンドプロンプトは、管理者

        として実行ではなく、通常起動したものです。)

        dir \\192.168.0.1\share\temp


     (2)不具合事象が発生する環境では、不具合事象が

        発生している状態で、タスクマネージャーを

        起動すると、trueが返されるようになりますが、

        その状態で、端末を再起動してサインインを

        しなおすと、falseが返されるようになります。

    以上、ご確認をお願いいたします。
    2020年3月15日 3:53

回答

  • Harukaさん、こんにちは。

    未読があることに気づかず、お返事遅くなり大変失礼いたしました。

    共有フォルダの存在チェック方法に関するアドバイス、ありがとうございます、参考にさせていただきます。

    その後の原因調査の結果、どうやら、共有フォルダ参照時に使用するユーザー名・パスワードが、共有フォルダ提供側と共有フォルダ参照側で一致しておらず、資格情報を指定して接続してアクセスする場合のみ、今回の事象が発生するようです。

    例えば、共有フォルダ提供側端末のローカルユーザーにuser01が存在するとして、共有フォルダ参照側端末へサインインしているユーザー名が(ドメインユーザーかワークグループユーザーかを問わず、)user01であれば、標準ユーザーアクセストークンでアクセスした状態でも管理者ユーザーアクセストークンでアクセスした状態でも、事象は発生しませんが、共有フォルダ参照側端末へサインインしているユーザー名がuser01以外だと、(資格情報マネージャーに事前にuser01の資格情報を登録していたとしても、)事象が発生することまではわかりました。

    (厳密には、標準ユーザーアクセストークンでアクセスすると事象は発生しませんが、管理者ユーザーアクセストークンでアクセスすると事象が発生します。また、ややこしいことに、事象が発生した状態で、UAC昇格するか、タスクマネージャー起動やタスクスケジューラー起動、イベントビューアー起動を行うと、事象は解消され、共有フォルダにアクセスが可能になります。)

    このあたりのWindowsOSの振る舞いが仕様どおりなのか、不具合なのかについては、時間をかけて、ちゃんと調べないと判別できそうにありませんでした。

    原因と対策方法を突き詰めたいのはやまやまなのですが、対策時間が限られているため、今回は、共有フォルダ提供側端末に、共有フォルダ参照側端末で使用するユーザー名と同じユーザー名のユーザーを登録することで、事象回避することとします。(ユーザーをどのグループにも所属させないことで、共有フォルダ提供側端末へサインインはできないユーザー認証専用イメージのユーザーを作る予定です。)

    情報共有やアドバイスをいただいた皆様、ご協力ありがとうございました。

    • 回答としてマーク おれんG3 2020年4月15日 7:25
    2020年4月15日 7:25

すべての返信

  • 192.168.0.1 は自分自身以外のサーバーなのですよね。

    Active Directory ドメイン構成でしょうか、ワークグループ構成でしょうか。
    サインイン直後は接続されておらず、何らかのアクション(エクスプローラーやタスクマネージャーの起動等)でセッションが確立されていて、その後、自動切断されていたということはないでしょうか。

    接続に使うアカウント情報が事前に分かっている場合は、WNetAddConnection2 API や New-PSDrive コマンドレットWshNetwork.MapNetrowkDrive メソッドなどを併用してセッションを確立してみるのは如何でしょう。

    2020年3月15日 4:54
  • 魔界の仮面弁士さん、返信ありがとうございます。

    >Active Directory ドメイン構成でしょうか、ワークグループ構成でしょうか。

    ADサーバーを立てているという話を聞いていないため、おそらくWORKGROUP構成と思われます。

    (確証がとれていない情報で恐縮です。)

    接続に使うアカウント情報が事前に分かっている場合は、~後略~

    なるほど、そういう手法もあるのですね。参考にさせていただきます。

    取り急ぎでは、共有フォルダにドライブレターを割り当ててアクセスすると、事象が回避できないか、確認してもらう予定です。

    (残念ながら、結果は、明日以降にならないと、わからない見込みですが。)

    以上、確認をお願いいたします。

    2020年3月15日 5:20
  • おれんG3さん、こんにちは。フォーラムオペレーターのHarukaです。
    MSDNフォーラムにご投稿くださいましてありがとうございます。

    私の調査では、Directory.Existsメソッドを使用して、共有ディレクトリが存在するかどうかを検出することはできません。
    Directory.Exists not working for a network pathをご確認して、その理由がわかります。

    また、次のリンクを参照して、共有ディレクトリが存在するかどうかを確認できます。
    How to (quickly) check if UNC Path is available

    このソリューションが役に立てれば幸いです。

    どうぞよろしくお願いいたします。

    MSDN/ TechNet Community Support Haruka
    ~参考になった投稿には「回答としてマーク」をご設定ください。なかった場合は「回答としてマークされていない」も設定できます。同じ問題で後から参照した方が、情報を見つけやすくなりますので、 ご協力くださいますようお願いいたします。また、MSDNサポートに賛辞や苦情がある場合は、MSDNFSF@microsoft.comまでお気軽にお問い合わせください。~

    2020年3月17日 8:35
    モデレータ
  • Harukaさん、こんにちは。

    未読があることに気づかず、お返事遅くなり大変失礼いたしました。

    共有フォルダの存在チェック方法に関するアドバイス、ありがとうございます、参考にさせていただきます。

    その後の原因調査の結果、どうやら、共有フォルダ参照時に使用するユーザー名・パスワードが、共有フォルダ提供側と共有フォルダ参照側で一致しておらず、資格情報を指定して接続してアクセスする場合のみ、今回の事象が発生するようです。

    例えば、共有フォルダ提供側端末のローカルユーザーにuser01が存在するとして、共有フォルダ参照側端末へサインインしているユーザー名が(ドメインユーザーかワークグループユーザーかを問わず、)user01であれば、標準ユーザーアクセストークンでアクセスした状態でも管理者ユーザーアクセストークンでアクセスした状態でも、事象は発生しませんが、共有フォルダ参照側端末へサインインしているユーザー名がuser01以外だと、(資格情報マネージャーに事前にuser01の資格情報を登録していたとしても、)事象が発生することまではわかりました。

    (厳密には、標準ユーザーアクセストークンでアクセスすると事象は発生しませんが、管理者ユーザーアクセストークンでアクセスすると事象が発生します。また、ややこしいことに、事象が発生した状態で、UAC昇格するか、タスクマネージャー起動やタスクスケジューラー起動、イベントビューアー起動を行うと、事象は解消され、共有フォルダにアクセスが可能になります。)

    このあたりのWindowsOSの振る舞いが仕様どおりなのか、不具合なのかについては、時間をかけて、ちゃんと調べないと判別できそうにありませんでした。

    原因と対策方法を突き詰めたいのはやまやまなのですが、対策時間が限られているため、今回は、共有フォルダ提供側端末に、共有フォルダ参照側端末で使用するユーザー名と同じユーザー名のユーザーを登録することで、事象回避することとします。(ユーザーをどのグループにも所属させないことで、共有フォルダ提供側端末へサインインはできないユーザー認証専用イメージのユーザーを作る予定です。)

    情報共有やアドバイスをいただいた皆様、ご協力ありがとうございました。

    • 回答としてマーク おれんG3 2020年4月15日 7:25
    2020年4月15日 7:25