404

私は.NET 3.5を使用しており、次を使用してディレクトリを再帰的に削除しようとしています:

Directory.Delete(myPath, true);

私の理解では、ファイルが使用されている場合、またはアクセス許可の問題がある場合、これはスローされるはずですが、それ以外の場合は、ディレクトリとそのすべてのコンテンツを削除する必要があります。

ただし、私は時々これを取得します:

System.IO.IOException: The directory is not empty.
    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
    at System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean recursive)
    at System.IO.Directory.Delete(String fullPath, String userPath, Boolean recursive)
    ...

メソッドが時々スローすることには驚きませんが、recursive が true のときにこの特定のメッセージが表示されることに驚きました。(ディレクトリが空ではないことはわかっています。)

AccessViolationException の代わりにこれが表示される理由はありますか?

4

27 に答える 27

241

編集者注:この回答にはいくつかの有用な情報が含まれていますが、の動作については実際には正しくありませんDirectory.Delete。この回答に対するコメント、およびこの質問に対する他の回答をお読みください。


私は以前にこの問題に遭遇しました。

問題の根本は、この関数がディレクトリ構造内にあるファイルを削除しないことです。したがって、ディレクトリ自体を削除する前に、ディレクトリ構造内のすべてのファイルを削除してから、すべてのディレクトリを削除する関数を作成する必要があります。これは2番目のパラメーターに反することはわかっていますが、はるかに安全なアプローチです。さらに、ファイルを削除する直前に、ファイルから読み取り専用アクセス属性を削除することをお勧めします。そうしないと、例外が発生します。

このコードをプロジェクトに打ち込むだけです。

public static void DeleteDirectory(string target_dir)
{
    string[] files = Directory.GetFiles(target_dir);
    string[] dirs = Directory.GetDirectories(target_dir);

    foreach (string file in files)
    {
        File.SetAttributes(file, FileAttributes.Normal);
        File.Delete(file);
    }

    foreach (string dir in dirs)
    {
        DeleteDirectory(dir);
    }

    Directory.Delete(target_dir, false);
}

C:\WINDOWS (%WinDir%)また、私は、誰かにこの関数をまたはで呼び出してもらいたいので、削除できるマシンの領域に制限を個人的に追加しますC:\

于 2008-11-30T22:24:23.023 に答える
45

先に進む前に、あなたの管理下にある次の理由を確認してください。

  • フォルダーはプロセスの現在のディレクトリとして設定されていますか? はいの場合は、最初に別のものに変更してください。
  • そのフォルダからファイルを開いた (または DLL をロードした) ことはありますか? (そしてそれを閉じる/アンロードするのを忘れた)

それ以外の場合は、制御できない次の正当な理由を確認してください。

  • そのフォルダには読み取り専用としてマークされたファイルがあります。
  • これらのファイルの一部に対する削除権限がありません。
  • ファイルまたはサブフォルダーがエクスプローラーまたは別のアプリで開かれている。

上記のいずれかが問題である場合は、削除コードを改善する前に、その理由を理解する必要があります。アプリで読み取り専用またはアクセスできないファイルを削除する必要がありますか? 誰がそのようにマークしたのですか?なぜですか?

上記の理由を除外した後でも、偽の障害が発生する可能性はまだあります。誰かが削除対象のファイルまたはフォルダーのハンドルを保持している場合、削除は失敗します。誰かがフォルダーを列挙したり、そのファイルを読み取ったりする理由は多数あります。

  • 検索インデクサー
  • アンチウイルス
  • バックアップ ソフトウェア

偽の失敗に対処するための一般的なアプローチは、試行の間に一時停止して、複数回試行することです。永遠に試行し続けたくないのは明らかなので、一定回数試行したらあきらめて、例外をスローするか、エラーを無視する必要があります。このような:

private static void DeleteRecursivelyWithMagicDust(string destinationDir) {
    const int magicDust = 10;
    for (var gnomes = 1; gnomes <= magicDust; gnomes++) {
        try {
            Directory.Delete(destinationDir, true);
        } catch (DirectoryNotFoundException) {
            return;  // good!
        } catch (IOException) { // System.IO.IOException: The directory is not empty
            System.Diagnostics.Debug.WriteLine("Gnomes prevent deletion of {0}! Applying magic dust, attempt #{1}.", destinationDir, gnomes);

            // see http://stackoverflow.com/questions/329355/cannot-delete-directory-with-directory-deletepath-true for more magic
            Thread.Sleep(50);
            continue;
        }
        return;
    }
    // depending on your use case, consider throwing an exception here
}

私の意見では、このようなヘルパーはすべての削除に使用する必要があります。これは、偽の失敗が常に発生する可能性があるためです。ただし、このコードをやみくもにコピーするのではなく、ユースケースに合わせて調整する必要があります。

%LocalAppData% の下にある、アプリによって生成された内部データ フォルダーで誤ったエラーが発生したため、分析は次のようになります。

  1. フォルダーは私のアプリケーションによってのみ制御され、ユーザーはそのフォルダー内のものを読み取り専用またはアクセス不可としてマークする正当な理由がないため、そのケースを処理しようとしません。

  2. そこにはユーザーが作成した貴重なものは含まれていないため、誤って何かを強制的に削除するリスクはありません。

  3. 内部データ フォルダーであるため、エクスプローラーで開くことは想定していません。少なくとも、ケースを具体的に処理する必要はないと思います (つまり、サポートを介してそのケースを処理できます)。

  4. すべての試行が失敗した場合、エラーを無視することを選択します。最悪の場合、アプリがいくつかの新しいリソースの解凍に失敗し、クラッシュしてユーザーにサポートへの連絡を促すメッセージが表示されますが、頻繁に発生しない限り、これは許容されます。または、アプリがクラッシュしない場合は、古いデータが残りますが、これも許容範囲です。

  5. 再試行を 500 ミリ秒 (50 * 10) に制限することにしました。これは、実際に機能する任意のしきい値です。ユーザーが応答を停止したと考えてアプリを強制終了しないように、しきい値を十分に短くしたかったのです。一方、0.5 秒は、犯罪者が私のフォルダーの処理を完了するのに十分な時間です。他の SO の回答から判断するSleep(0)と、受け入れられることさえある場合があるため、1 回以上の再試行を経験するユーザーはほとんどいません。

  6. 50 ミリ秒ごとに再試行しますが、これは別の任意の数値です。ファイルを削除しようとしたときにファイルが処理中 (インデックス作成、チェック中) である場合、私の場合、50 ミリ秒が処理の完了を期待するのに適切な時間であると感じています。また、50 ミリ秒は十分に小さいため、顕著な速度低下は発生しません。繰り返しSleep(0)ますが、多くの場合は十分であるように思われるので、あまり遅らせたくありません。

  7. コードは IO 例外で再試行します。通常、%LocalAppData% にアクセスする例外は想定していないので、シンプルさを選択し、正当な例外が発生した場合に備えて 500 ミリ秒の遅延のリスクを受け入れました。また、再試行したい正確な例外を検出する方法を見つけたくありませんでした。

于 2013-02-18T10:15:32.790 に答える
20

最新の非同期回答

受け入れられた答えは単純に間違っています。ディスクからファイルを取得するのにかかる時間がファイルをロックしていたものを解放するため、一部の人にとってはうまくいくかもしれません。実際、これはファイルが他のプロセス/ストリーム/アクションによってロックされるために発生します。他の回答では、Thread.Sleep(Yuck) を使用して、しばらくしてからディレクトリの削除を再試行します。この質問は、より現代的な回答で再検討する必要があります。

public static async Task<bool> TryDeleteDirectory(
   string directoryPath,
   int maxRetries = 10,
   int millisecondsDelay = 30)
{
    if (directoryPath == null)
        throw new ArgumentNullException(directoryPath);
    if (maxRetries < 1)
        throw new ArgumentOutOfRangeException(nameof(maxRetries));
    if (millisecondsDelay < 1)
        throw new ArgumentOutOfRangeException(nameof(millisecondsDelay));

    for (int i = 0; i < maxRetries; ++i)
    {
        try
        {
            if (Directory.Exists(directoryPath))
            {
                Directory.Delete(directoryPath, true);
            }

            return true;
        }
        catch (IOException)
        {
            await Task.Delay(millisecondsDelay);
        }
        catch (UnauthorizedAccessException)
        {
            await Task.Delay(millisecondsDelay);
        }
    }

    return false;
}

単体テスト

これらのテストは、ロックされたファイルによって がDirectory.Delete失敗する原因と、TryDeleteDirectory上記の方法で問題が解決される方法の例を示しています。

[Fact]
public async Task TryDeleteDirectory_FileLocked_DirectoryNotDeletedReturnsFalse()
{
    var directoryPath = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString());
    var subDirectoryPath = Path.Combine(Path.GetTempPath(), "SubDirectory");
    var filePath = Path.Combine(directoryPath, "File.txt");

    try
    {
        Directory.CreateDirectory(directoryPath);
        Directory.CreateDirectory(subDirectoryPath);

        using (var fileStream = new FileStream(filePath, FileMode.Create, FileAccess.Write, FileShare.Write))
        {
            var result = await TryDeleteDirectory(directoryPath, 3, 30);
            Assert.False(result);
            Assert.True(Directory.Exists(directoryPath));
        }
    }
    finally
    {
        if (Directory.Exists(directoryPath))
        {
            Directory.Delete(directoryPath, true);
        }
    }
}

[Fact]
public async Task TryDeleteDirectory_FileLockedThenReleased_DirectoryDeletedReturnsTrue()
{
    var directoryPath = Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString());
    var subDirectoryPath = Path.Combine(Path.GetTempPath(), "SubDirectory");
    var filePath = Path.Combine(directoryPath, "File.txt");

    try
    {
        Directory.CreateDirectory(directoryPath);
        Directory.CreateDirectory(subDirectoryPath);

        Task<bool> task;
        using (var fileStream = new FileStream(filePath, FileMode.Create, FileAccess.Write, FileShare.Write))
        {
            task = TryDeleteDirectory(directoryPath, 3, 30);
            await Task.Delay(30);
            Assert.True(Directory.Exists(directoryPath));
        }

        var result = await task;
        Assert.True(result);
        Assert.False(Directory.Exists(directoryPath));
    }
    finally
    {
        if (Directory.Exists(directoryPath))
        {
            Directory.Delete(directoryPath, true);
        }
    }
}
于 2017-06-02T08:33:11.563 に答える
18

言及すべき重要な点の 1 つ (コメントとして追加しましたが、許可されていません) は、オーバーロードの動作が .NET 3.5 から .NET 4.0 に変更されたことです。

Directory.Delete(myPath, true);

.NET 4.0 以降では、フォルダー自体のファイルは削除されますが、3.5 では削除されません。これは、MSDN のドキュメントでも確認できます。

.NET 4.0

指定されたディレクトリを削除し、指定されている場合はディレクトリ内のすべてのサブディレクトリとファイルを削除します。

.NET 3.5

空のディレクトリを削除し、指定されている場合はディレクトリ内のすべてのサブディレクトリとファイルを削除します。

于 2016-11-24T14:38:00.323 に答える
15

Delphiでもまったく同じ問題がありました。最終的に、自分のアプリケーションが、削除したいディレクトリをロックしていました。ディレクトリに書き込んでいるときに、どういうわけかディレクトリがロックされました(いくつかの一時ファイル)。

キャッチ22は、削除する前に親に簡単な変更ディレクトリを作成したことです。

于 2008-11-30T21:02:27.260 に答える
12

次のコマンドを実行すると、エラーを再現できます。

Directory.CreateDirectory(@"C:\Temp\a\b\c\");
Process.Start(@"C:\Temp\a\b\c\");
Thread.Sleep(1000);
Directory.Delete(@"C:\Temp\a\b\c");
Directory.Delete(@"C:\Temp\a\b");
Directory.Delete(@"C:\Temp\a");

ディレクトリ 'b' を削除しようとすると、「ディレクトリが空ではありません」という IOException がスローされます。ディレクトリ「c」を削除したばかりなので、それはばかげています。

私の理解では、説明はディレクトリ「c」が削除済みとしてスタンプされているということです。ただし、削除はシステムでまだコミットされていません。システムはジョブが完了したと応答しましたが、実際にはまだ処理中です。システムはおそらく、ファイル エクスプローラーが親ディレクトリにフォーカスして削除をコミットするのを待ちます。

Delete 関数のソース コード ( http://referencesource.microsoft.com/#mscorlib/system/io/directory.cs ) を見ると、ネイティブの Win32Native.RemoveDirectory 関数を使用していることがわかります。この do-not-wait 動作は次のとおりです。

RemoveDirectory 関数は、閉じるときに削除するディレクトリをマークします。したがって、ディレクトリへの最後のハンドルが閉じられるまで、ディレクトリは削除されません。

( http://msdn.microsoft.com/en-us/library/windows/desktop/aa365488(v=vs.85).aspx )

スリープして再試行することが解決策です。ryasclのソリューションを参照してください。

于 2014-09-05T08:06:12.860 に答える
11

それぞれの読み取り専用属性を変更する必要なく、読み取り専用ファイルを含むディレクトリを削除できる、この単純な非再帰的な方法を誰も考えなかったことに驚いています。

Process.Start("cmd.exe", "/c " + @"rmdir /s/q C:\Test\TestDirectoryContainingReadOnlyFiles"); 

(インターネット全体で利用可能なコマンドウィンドウを一時的に起動しないように少し変更します)

于 2012-06-02T05:54:17.447 に答える
8

Explorer シェルで実行できるにもかかわらず、ユーザー プロファイル ディレクトリ (C:\Documents and Settings 内) を削除する際に、奇妙なアクセス許可の問題が発生しました。

File.SetAttributes(target_dir, FileAttributes.Normal);
Directory.Delete(target_dir, false);

「ファイル」操作がディレクトリに対して何をするのか、私には意味がありませんが、それが機能することはわかっており、それで十分です!

于 2009-06-11T14:14:33.980 に答える
3

ファイルを削除しない再帰的なディレクトリ削除は、確かに予想外です。そのための私の修正:

public class IOUtils
{
    public static void DeleteDirectory(string directory)
    {
        Directory.GetFiles(directory, "*", SearchOption.AllDirectories).ForEach(File.Delete);
        Directory.Delete(directory, true);
    }
}

これが役立つケースを経験しましたが、一般的に、Directory.Deleteは msdn に記載されているように、再帰的な削除時にディレクトリ内のファイルを削除します。

Windows エクスプローラーのユーザーとしても、この不規則な動作に時々遭遇します。フォルダーを削除できない場合があります (無意味なメッセージは「アクセスが拒否されました」と思われます)。アイテムも。したがって、上記のコードは、基本クラス ライブラリの問題ではなく、OS の異常を扱っていると思います。

于 2013-05-01T15:38:31.813 に答える
3

この回答は、 https://stackoverflow.com/a/1703799/184528に基づいています。私のコードとの違いは、Directory.Delete の呼び出しが最初の試行で失敗する必要がある場合にのみ、多くの削除サブディレクトリとファイルを再帰することです (これは、Windows エクスプローラーがディレクトリを参照しているために発生する可能性があります)。

    public static void DeleteDirectory(string dir, bool secondAttempt = false)
    {
        // If this is a second try, we are going to manually 
        // delete the files and sub-directories. 
        if (secondAttempt)
        {
            // Interrupt the current thread to allow Explorer time to release a directory handle
            Thread.Sleep(0);

            // Delete any files in the directory 
            foreach (var f in Directory.GetFiles(dir, "*.*", SearchOption.TopDirectoryOnly))
                File.Delete(f);

            // Try manually recursing and deleting sub-directories 
            foreach (var d in Directory.GetDirectories(dir))
                DeleteDirectory(d);

            // Now we try to delete the current directory
            Directory.Delete(dir, false);
            return;
        }

        try
        {
            // First attempt: use the standard MSDN approach.
            // This will throw an exception a directory is open in explorer
            Directory.Delete(dir, true);
        }
        catch (IOException)
        {
            // Try again to delete the directory manually recursing. 
            DeleteDirectory(dir, true);
        }
        catch (UnauthorizedAccessException)
        {
            // Try again to delete the directory manually recursing. 
            DeleteDirectory(dir, true);
        } 
    }
于 2016-08-04T21:07:02.127 に答える
2

この問題やその他の例外を解決するために、ディレクトリを削除するのに数時間を費やしました。これが私の解決策です

 public static void DeleteDirectory(string target_dir)
    {
        DeleteDirectoryFiles(target_dir);
        while (Directory.Exists(target_dir))
        {
            lock (_lock)
            {
                DeleteDirectoryDirs(target_dir);
            }
        }
    }

    private static void DeleteDirectoryDirs(string target_dir)
    {
        System.Threading.Thread.Sleep(100);

        if (Directory.Exists(target_dir))
        {

            string[] dirs = Directory.GetDirectories(target_dir);

            if (dirs.Length == 0)
                Directory.Delete(target_dir, false);
            else
                foreach (string dir in dirs)
                    DeleteDirectoryDirs(dir);
        }
    }

    private static void DeleteDirectoryFiles(string target_dir)
    {
        string[] files = Directory.GetFiles(target_dir);
        string[] dirs = Directory.GetDirectories(target_dir);

        foreach (string file in files)
        {
            File.SetAttributes(file, FileAttributes.Normal);
            File.Delete(file);
        }

        foreach (string dir in dirs)
        {
            DeleteDirectoryFiles(dir);
        }
    }

このコードにはわずかな遅延がありますが、これは私のアプリケーションにとって重要ではありません。ただし、削除するディレクトリ内に多数のサブディレクトリがある場合は、遅延が問題になる可能性があることに注意してください。

于 2011-09-22T17:17:57.357 に答える
2

別のスレッドまたはプロセスがディレクトリにファイルを追加している競合状態が発生している可能性はありますか:

シーケンスは次のようになります。

削除プロセス A:

  1. ディレクトリを空にする
  2. (空になった) ディレクトリを削除します。

他の誰かが 1 と 2 の間にファイルを追加した場合、おそらく 2 がリストされた例外をスローするでしょうか?

于 2008-11-30T21:29:37.953 に答える
1

この問題は、パスの長さが 260 シンボルを超えるディレクトリ (または任意のサブディレクトリ) にファイルがある場合に、Windows で発生する可能性があります。

そのような場合は、\\\\?\C:\mydir代わりに削除する必要がありますC:\mydir。260 シンボルの制限については、こちらを参照してください。

于 2016-11-11T14:34:43.347 に答える
1

今日はこの問題がありました。これは、削除しようとしていたディレクトリに対して Windows エクスプローラーを開いていたため、再帰呼び出しが失敗し、IOException が発生したために発生していました。ディレクトリに対して開いているハンドルがないことを確認してください。

また、MSDN は、独自の再帰を記述する必要がないことを明確にしています: http://msdn.microsoft.com/en-us/library/fxeahc5f.aspx

于 2011-03-28T22:07:31.180 に答える
1

これは、FileChangesNotifications によるものです。

ASP.NET 2.0 以降で発生します。アプリ内のフォルダーを削除すると、再起動されます。ASP.NET Health Monitoringを使用して、自分で確認できます 。

このコードを web.config/configuration/system.web に追加するだけです:

<healthMonitoring enabled="true">
  <rules>
    <add name="MyAppLogEvents" eventName="Application Lifetime Events" provider="EventLogProvider" profile="Critical"/>
  </rules>
</healthMonitoring>


その後、チェックアウトしWindows Log -> Applicationます。何が起こっている:

フォルダを削除するとき、サブフォルダがある場合は、サブフォルダを先にDelete(path, true)削除します。FileChangesMonitor が削除について認識し、アプリをシャットダウンするだけで十分です。一方、メイン ディレクトリはまだ削除されていません。これはログからのイベントです:


ここに画像の説明を入力


Delete()作業が完了せず、アプリがシャットダウンしているため、例外が発生します。

ここに画像の説明を入力

削除するフォルダーにサブフォルダーがない場合、Delete() はすべてのファイルとそのフォルダーを削除するだけで、アプリも再起動されますが、アプリの再起動は何も中断しないため、例外は発生しません。それでも、進行中のセッションはすべて失われ、アプリは再起動時にリクエストに応答しません。

今何?

この動作を無効にするためのいくつかの回避策と微調整、Directory JunctionTurning Off FCN with RegistryStopping FileChangesMonitor using Reflection (公開されたメソッドがないため) がありますが、それらはすべて正しくないようです。理由。データの構造ではなく、アプリの構造を管理しています。簡単な答えは次のとおりです。削除するフォルダーをアプリの外に配置します。FileChangesMonitor は通知を受け取らず、アプリは毎回再起動されません。例外はありません。それらを Web から表示するには、次の 2 つの方法があります。

  1. 着信呼び出しを処理し、アプリの外部 (wwwroot の外部) のフォルダーから読み取ることによってファイルを返すコントローラーを作成します。

  2. プロジェクトが大きく、パフォーマンスが最も重要である場合は、静的コンテンツを提供するための個別の小型で高速な Web サーバーをセットアップします。したがって、IIS に彼の特定の仕事を任せます。同じマシン (Windows の場合は mongoose) または別のマシン (Linux の場合は nginx) にある可能性があります。Linux で静的コンテンツ サーバーをセットアップするために追加の Microsoft ライセンスを支払う必要はありません。

お役に立てれば。

于 2013-11-26T10:39:33.890 に答える
1

Windows エクスプローラーでパスまたはサブフォルダーを選択するだけで、Directory.Delete(path, true) の 1 回の実行をブロックでき、上記のように IOException をスローし、Windows エクスプローラーを親フォルダーから起動して次のように処理する代わりに終了します。期待される。

于 2010-02-24T19:32:40.440 に答える
1

ディレクトリまたはその中のファイルはロックされており、削除できません。それをロックしている犯人を見つけて、それを排除できるかどうかを確認してください。

于 2008-11-30T21:31:21.413 に答える
1

TFS2012 を使用するビルド サーバー上の Windows Workflow Foundation で同じ問題が発生しました。内部的には、再帰フラグを true に設定して Directory.Delete() を呼び出すワークフロー。私たちの場合、ネットワークに関連しているようです。

最新のバイナリを再作成して再設定する前に、ネットワーク共有のバイナリ ドロップ フォルダを削除していました。他のすべてのビルドは失敗します。ビルドが失敗した後にドロップ フォルダーを開くと、フォルダーは空でした。これは、実際のディレクトリの削除を除いて、Directory.Delete() 呼び出しのすべての側面が成功したことを示しています。

この問題は、ネットワーク ファイル通信の非同期性が原因であると思われます。ビルド サーバーはファイル サーバーにすべてのファイルを削除するように指示し、ファイル サーバーは完全に終了していないにもかかわらず、削除したことを報告しました。その後、ビルド サーバーはディレクトリの削除を要求し、ファイル サーバーはファイルの削除が完全に完了していないため、要求を拒否しました。

この場合の 2 つの解決策:

  • 各ステップ間の遅延と検証を使用して、独自のコードで再帰的な削除を構築します
  • IOException の後で最大 X 回再試行し、再試行する前に遅延を与えます

後者の方法は手早く汚いですが、うまくいくようです。

于 2013-07-24T15:28:43.557 に答える
1

私はこの千年のテクニックで解決しました(キャッチでThread.Sleepをそのままにしておくことができます)

bool deleted = false;
        do
        {
            try
            {
                Directory.Delete(rutaFinal, true);                    
                deleted = true;
            }
            catch (Exception e)
            {
                string mensaje = e.Message;
                if( mensaje == "The directory is not empty.")
                Thread.Sleep(50);
            }
        } while (deleted == false);
于 2018-10-29T19:37:21.933 に答える
0

ネットワークファイルの場合、Directory.DeleteHelper(recursive:= true)により、ファイルの削除の遅延が原因でIOExceptionが発生する可能性があります

于 2011-03-03T02:12:05.770 に答える
0

メソッドが非同期で、次のようにコーディングされている場合に、上記の問題の可能性のあるインスタンスを 1 つ解決しました。

// delete any existing update content folder for this update
if (await fileHelper.DirectoryExistsAsync(currentUpdateFolderPath))
       await fileHelper.DeleteDirectoryAsync(currentUpdateFolderPath);

これとともに:

bool exists = false;                
if (await fileHelper.DirectoryExistsAsync(currentUpdateFolderPath))
    exists = true;

// delete any existing update content folder for this update
if (exists)
    await fileHelper.DeleteDirectoryAsync(currentUpdateFolderPath);

結論?Microsoft が話すことができなかった、存在を確認するために使用されるハンドルを取り除くことには、いくつかの非同期的な側面があります。if ステートメント内の非同期メソッドに、using ステートメントのように動作する if ステートメントがあるかのようです。

于 2016-10-28T18:51:15.460 に答える
0

アプリケーション (または他のアプリケーション) の現在のディレクトリが削除しようとしている場合、アクセス違反エラーにはなりませんが、ディレクトリは空ではありません。現在のディレクトリを変更して、自分のアプリケーションではないことを確認してください。また、ディレクトリが他のプログラム (Word、Excel、Total Commander など) で開かれていないことを確認してください。ほとんどのプログラムは、最後に開いたファイルのディレクトリに cd します。これが原因です。

于 2008-11-30T23:38:10.473 に答える