.NET 3.5를 사용하고 있는데 다음을 사용하여 디렉토리를 반복적으로 삭제하려고합니다.

Directory.Delete(myPath, true);

파일을 사용 중이거나 권한 문제가있는 경우이를 throw해야하지만 그렇지 않으면 디렉토리와 모든 내용을 삭제해야합니다.

그러나 때때로 나는 이것을 얻는다 :

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)
    ...

이 방법이 때때로 발생한다는 사실은 놀랍지 않지만 재귀가 참일 때이 특정 메시지를 얻는 것에 놀랐습니다. ( 디렉토리가 비어 있지 않다는 것을 알고 있습니다.)

AccessViolationException 대신 이것을 볼 이유가 있습니까?

편집자 주 : 이 답변에는 유용한 정보가 포함되어 있지만의 작동 방식에 대해서는 실제로 잘못되었습니다 Directory.Delete. 이 답변에 대한 의견과이 질문에 대한 다른 답변을 읽으십시오.

나는 전에이 문제에 부딪쳤다.

문제의 근본 원인은이 함수가 디렉토리 구조 내에있는 파일을 삭제하지 않는다는 것입니다. 따라서 디렉토리 자체를 제거하기 전에 디렉토리 구조 내의 모든 파일을 삭제 한 다음 모든 디렉토리를 삭제하는 함수를 작성해야합니다. 나는 이것이 두 번째 매개 변수에 위배된다는 것을 알고 있지만 훨씬 안전한 접근 방식입니다. 또한 파일을 삭제하기 직전에 파일에서 읽기 전용 액세스 속성을 제거하려고 할 수 있습니다. 그렇지 않으면 예외가 발생합니다.

이 코드를 프로젝트에 넣으십시오.

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:\.

재귀 적으로 디렉토리를 삭제하려고 시도하고 탐색기에서 a디렉토리 a\b가 열려 b있으면 삭제되지만 a이동하고 볼 때 디렉토리가 비어 있어도 '디렉토리가 비어 있지 않습니다'라는 오류 가 발생합니다. 모든 응용 프로그램 (탐색기 포함)의 현재 디렉토리는 디렉토리에 대한 핸들을 유지합니다 . 당신이 호출 할 때 Directory.Delete(true), 그것은 아래에서 위로 삭제합니다 b다음 a. b탐색기에서이 열려 있으면 탐색기에서 삭제를 감지하고 b디렉토리를 위쪽으로 변경 cd ..하며 열린 핸들을 정리합니다. 파일 시스템이 비동기 적으로 작동하기 때문에 Directory.Delete탐색기와의 충돌로 인해 작업이 실패합니다.

불완전한 솔루션

필자는 탐색기 스레드가 디렉토리 핸들을 해제 할 수 있도록 현재 스레드를 중단한다는 아이디어와 함께 다음 솔루션을 게시했습니다.

// incomplete!
try
{
    Directory.Delete(path, true);
}
catch (IOException)
{
    Thread.Sleep(0);
    Directory.Delete(path, true);
}

그러나 열린 디렉토리가 삭제하려는 디렉토리 의 바로 하위 인 경우에만 작동합니다 . 경우 a\b\c\d탐색기에서 열려 있고이에를 사용 a,이 기술은 삭제 한 후 실패 d하고 c.

다소 더 나은 솔루션

이 방법은 하위 디렉토리 중 하나가 탐색기에서 열려 있어도 깊은 디렉토리 구조의 삭제를 처리합니다.

/// <summary>
/// Depth-first recursive delete, with handling for descendant 
/// directories open in Windows Explorer.
/// </summary>
public static void DeleteDirectory(string path)
{
    foreach (string directory in Directory.GetDirectories(path))
    {
        DeleteDirectory(directory);
    }

    try
    {
        Directory.Delete(path, true);
    }
    catch (IOException) 
    {
        Directory.Delete(path, true);
    }
    catch (UnauthorizedAccessException)
    {
        Directory.Delete(path, true);
    }
}

우리 자신의 재발의 추가 작업에도 불구하고, 우리는 여전히UnauthorizedAccessException 길을 따라 발생할 수있는 것을 처리해야 합니다. 첫 번째 삭제 시도가 두 번째, 성공한 시도를위한 길을 닦고 있는지 또는 파일 시스템이 따라 올 수있는 예외를 던지거나 잡는 데서 발생하는 타이밍 지연인지는 확실하지 않습니다.

블록 Thread.Sleep(0)의 시작 부분에 a 를 추가하여 일반적인 조건에서 발생하고 포착되는 예외 수를 줄일 수 있습니다 try. 또한 시스템로드가 많은 경우 두 가지 Directory.Delete시도 를 모두 수행 하여 실패 할 수있는 위험이 있습니다. 이 솔루션을보다 강력한 재귀 삭제의 시작점으로 고려하십시오.

일반적인 답변

이 솔루션은 Windows 탐색기와 상호 작용하는 특성 만 해결합니다. 견고한 삭제 작업을 원할 경우, 무엇이든 (바이러스 스캐너 등) 언제라도 삭제하려는 항목에 대해 열린 핸들을 가질 수 있다는 점을 명심해야합니다. 따라서 나중에 다시 시도해야합니다. 나중에 얼마나 많이 시도하고 몇 번 시도하는지는 개체를 삭제하는 것이 얼마나 중요한지에 달려 있습니다. 으로 MSDN을 나타냅니다 ,

강력한 파일 반복 코드는 파일 시스템의 많은 복잡성을 고려해야합니다.

NTFS 참조 문서에 대한 링크 만 제공되는이 무고한 진술은 머리카락을 돋보이게해야합니다.

( 편집 : 많이.이 답변은 원래 첫 번째, 불완전한 솔루션 만 가지고있었습니다.)

계속 진행하기 전에 제어 할 수있는 다음 이유를 확인하십시오.

• 폴더가 프로세스의 현재 디렉토리로 설정되어 있습니까? 그렇다면 먼저 다른 것으로 변경하십시오.
• 해당 폴더에서 파일을 열거 나 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. 재 시도를 500ms (50 * 10)로 제한합니다. 이것은 실제로 작동하는 임의의 임계 값입니다. 사용자가 응답을 멈췄다 고 생각하면서 앱을 죽이지 않도록 임계 값을 짧게 만들고 싶었습니다. 반면에, 0.5 초는 범죄자가 내 폴더 처리를 마치는 데 충분한 시간입니다. 때로는 Sleep(0)받아 들일 수있는 것으로 보이는 다른 SO 답변으로 판단 할 때, 한 번의 재시도 이상을 경험하는 사용자는 거의 없습니다.

6. 나는 50ms마다 다시 시도하는데, 이는 또 다른 임의의 숫자입니다. 파일을 삭제하려고 할 때 파일을 처리 (인덱싱, 검사)하면 50ms가 필자의 경우 처리가 완료 될 것으로 예상되는 시점입니다. 또한 50ms는 눈에 띄게 느려지지 않을 정도로 작습니다. 다시 말하지만, Sleep(0)많은 경우에 충분한 것으로 보이므로 너무 지연하고 싶지 않습니다.

7. 코드는 모든 IO 예외에서 재 시도합니다. 나는 일반적으로 % LocalAppData %에 액세스하는 예외를 기대하지 않으므로, 단순성을 선택하고 합법적 인 예외가 발생할 경우 500ms 지연의 위험을 감수했습니다. 또한 다시 시도하려는 정확한 예외를 감지하는 방법을 알고 싶지 않았습니다.

현대 비동기 답변

허용되는 대답은 잘못되었습니다. 디스크에서 파일을 가져 오는 데 걸리는 시간이 파일을 잠그는 모든 것을 해제하기 때문에 일부 사람들에게는 효과가있을 수 있습니다. 사실 이것은 다른 프로세스 / 스트림 / 액션에 의해 파일이 잠겨 있기 때문에 발생합니다. 다른 답변은 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);
        }
    }
}

언급해야 할 중요한 사항 중 하나는 주석으로 추가했지만 허용되지는 않습니다. 오버로드의 동작이 .NET 3.5에서 .NET 4.0으로 변경되었다는 것입니다.

Directory.Delete(myPath, true);

.NET 4.0부터는 3.5 폴더가 아닌 폴더 자체의 파일을 삭제합니다. 이것은 MSDN 설명서에서도 볼 수 있습니다.

.NET 4.0

지정된 디렉토리 및 지정된 경우 디렉토리의 서브 디렉토리 및 파일을 삭제 합니다 .

.NET 3.5

비어있는 디렉토리 와 표시된 경우 디렉토리의 하위 디렉토리 및 파일을 삭제 합니다 .

델파이에서도 똑같은 문제가있었습니다. 그리고 최종 결과는 내 응용 프로그램이 삭제하려는 디렉토리를 잠그고 있다는 것입니다. 어떻게 든 디렉토리에 쓸 때 디렉토리가 잠겼습니다 (일부 임시 파일).

캐치 22는 삭제하기 전에 부모로 간단한 변경 디렉토리 를 만들었 습니다.

나는이 간단한 비 재귀 적 방법에 대해 아무도 생각하지 않아 놀랐습니다.이 방법은 각 파일의 읽기 전용 속성을 변경할 필요없이 읽기 전용 파일을 포함하는 디렉토리를 삭제할 수 있습니다.

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

(인터넷을 통해 사용할 수있는 cmd 창을 일시적으로 실행하지 않도록 비트를 변경하십시오)

다음을 실행하여 오류를 재현 할 수 있습니다.

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'는 삭제 된 것으로 표시됩니다. 그러나 시스템에서 삭제가 아직 커밋되지 않았습니다. 시스템이 작업이 완료되었다고 응답했지만 실제로 처리 중입니다. 시스템은 파일 탐색기가 상위 디렉토리에 집중하여 삭제를 커미트하기를 기다릴 수 있습니다.

삭제 기능 ( http://referencesource.microsoft.com/#mscorlib/system/io/directory.cs ) 의 소스 코드를 보면 기본 Win32Native.RemoveDirectory 기능을 사용하는 것을 볼 수 있습니다. 이 대기하지 않는 동작은 다음과 같습니다.

RemoveDirectory 함수는 디렉토리를 닫을 때 삭제하도록 표시합니다. 따라서 디렉토리에 대한 마지막 핸들이 닫힐 때까지 디렉토리가 제거되지 않습니다.

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

수면 및 재 시도가 해결책입니다. ryascl의 솔루션을 참조하십시오.

Explorer 셸에서 그렇게 할 수는 있지만 C : \ Documents and Settings에서 User Profile 디렉토리를 삭제하는 이상한 권한 문제가있었습니다.

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

디렉토리에서 "파일"작업이 수행하는 작업은 이해가되지 않지만 작동한다는 것은 알고 있습니다.

이 답변은 https://stackoverflow.com/a/1703799/184528에 근거합니다 . 내 코드와의 차이점은 필요한 경우 Directory 삭제에 대한 많은 호출 하위 디렉토리와 파일 만 재귀한다는 것입니다. 첫 번째 시도에서 디렉토리가 삭제되어 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);
        } 
    }

위의 솔루션 중 어느 것도 나를 위해 잘 작동하지 않았습니다. 나는 다음과 같이 @ryascl 솔루션의 편집 버전을 사용하여 끝났습니다.

    /// <summary>
    /// Depth-first recursive delete, with handling for descendant 
    /// directories open in Windows Explorer.
    /// </summary>
    public static void DeleteDirectory(string path)
    {
        foreach (string directory in Directory.GetDirectories(path))
        {
            Thread.Sleep(1);
            DeleteDir(directory);
        }
        DeleteDir(path);
    }

    private static void DeleteDir(string dir)
    {
        try
        {
            Thread.Sleep(1);
            Directory.Delete(dir, true);
        }
        catch (IOException)
        {
            DeleteDir(dir);
        }
        catch (UnauthorizedAccessException)
        {
            DeleteDir(dir);
        }
    }

다른 스레드 또는 프로세스가 디렉토리에 파일을 추가하는 경쟁 조건이있을 수 있습니까?

순서는 다음과 같습니다.

삭제 프로세스 A :

1. 디렉토리 비우기
2. (현재 비어있는) 디렉토리를 삭제하십시오.

다른 사람이 1과 2 사이에 파일을 추가하면 2가 예외를 throw합니까?

이 문제와 디렉토리 삭제와 관련된 다른 예외를 해결하는 데 몇 시간을 보냈습니다. 이것은 나의 해결책이다

 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);
        }
    }

이 코드는 약간의 지연이 있으므로 내 응용 프로그램에는 중요하지 않습니다. 그러나 삭제하려는 디렉토리 내에 많은 서브 디렉토리가있는 경우 지연이 문제가 될 수 있습니다.

파일을 삭제하지 않는 재귀 디렉토리 삭제는 예상치 못한 결과입니다. 그에 대한 내 수정 :

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 이상을 처리한다고 생각합니다.

디렉토리 또는 파일이 잠겨있어서 삭제할 수 없습니다. 잠그는 범인을 찾아 제거 할 수 있는지 확인하십시오.

Windows 탐색기에서 경로 또는 하위 폴더를 선택하면 Directory.Delete (path, true)의 단일 실행이 차단되어 위에서 설명한대로 IOException이 발생하고 Windows 탐색기를 상위 폴더로 부팅하고 다음과 같이 진행하는 대신 죽어가는 것으로 보입니다 예상했다.

오늘이 문제가있었습니다. 삭제하려는 디렉토리에 Windows 탐색기가 열려 재귀 호출이 실패하여 IOException이 발생했기 때문에 발생했습니다. 디렉토리에 열린 핸들이 없는지 확인하십시오.

또한 MSDN은 사용자가 자신의 recusion을 작성할 필요가 없음을 분명합니다 : http://msdn.microsoft.com/en-us/library/fxeahc5f.aspx

TFS2012가있는 빌드 서버에서 Windows Workflow Foundation과 동일한 문제가 발생했습니다. 내부적으로 재귀 플래그가 true로 설정된 워크 플로는 Directory.Delete ()입니다. 우리의 경우 네트워크와 관련된 것으로 보입니다.

네트워크 공유에서 이진 드롭 폴더를 삭제하고 최신 이진 파일로 다시 채우고 다시 채웠습니다. 다른 모든 빌드는 실패합니다. 실패한 빌드 후 드롭 폴더를 열면 폴더가 비어 있습니다. 이는 실제로 디렉토리를 삭제하는 것을 제외하고 Directory.Delete () 호출의 모든 측면이 성공했음을 나타냅니다.

네트워크 파일 통신의 비동기 특성으로 인해 문제가 발생한 것으로 보입니다. 빌드 서버는 파일 서버에 모든 파일을 삭제하도록 지시했으며 파일 서버는 파일이 완전히 완료되지 않았더라도 파일이 있다고보고했습니다. 그런 다음 빌드 서버는 디렉토리 삭제를 요청했으며 파일 서버는 파일 삭제가 완전히 완료되지 않아 요청을 거부했습니다.

우리의 경우 두 가지 가능한 솔루션 :

• 각 단계 사이의 지연 및 검증을 통해 자체 코드에서 재귀 삭제를 빌드하십시오.
• IOException 후 X 번까지 다시 시도하여 다시 시도하기 전에 지연

후자의 방법은 빠르고 더럽지 만 트릭을 수행하는 것 같습니다.

FileChangesNotifications 때문입니다 .

ASP.NET 2.0 이후에 발생합니다. 앱에서 일부 폴더를 삭제 하면 다시 시작 됩니다. ASP.NET 상태 모니터링을 사용하여 직접 볼 수 있습니다 .

이 코드를 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가 앱 제거 및 종료에 대해 알고 있으면 충분합니다. 한편 기본 디렉토리는 아직 삭제되지 않았습니다. 이것은 Log의 이벤트입니다.

Delete() 작업이 완료되지 않고 앱이 종료되어 예외가 발생합니다.

이 때 하위 폴더가없는 당신이 삭제되는 폴더에, 단지 모든 파일과 폴더가, 응용 프로그램도 다시 시작지고 삭제 () 삭제,하지만 당신은 예외를하지 않는 응용 프로그램을 다시 시작 인터럽트 아무것도하지 않습니다 때문이다. 그러나 여전히 모든 프로세스 내 세션이 손실되고 다시 시작할 때 앱이 요청에 응답하지 않습니다.

지금 무엇?

이 동작, 디렉토리 접합 , 레지스트리로 FCN 끄기 , 리플렉션을 사용하여 FileChangesMonitor 중지 (노출 된 방법이 없기 때문에) 를 사용하지 않도록 설정하는 몇 가지 해결 방법과 조정이 있지만 FCN이 이유. 데이터 구조 가 아닌 앱 구조를 찾고 있습니다 . 짧은 대답은 앱 외부에 삭제하려는 폴더를 배치하는 것입니다. FileChangesMonitor는 알림을받지 않으며 매번 앱이 다시 시작되지 않습니다. 예외는 없습니다. 웹에서 볼 수있게하려면 다음 두 가지 방법이 있습니다.

1. 수신 전화를 처리 한 다음 앱 외부 폴더 (wwwroot 외부)를 읽어 파일을 다시 서비스하는 컨트롤러를 만듭니다.

2. 프로젝트가 크고 성능이 가장 중요한 경우 정적 컨텐츠를 제공하기 위해 작고 빠른 웹 서버를 별도로 설정하십시오. 따라서 IIS에 특정 작업을 맡기게됩니다. 동일한 시스템 (Windows의 경우 mongoose) 또는 다른 시스템 (Linux의 경우 nginx)에있을 수 있습니다. 좋은 소식은 리눅스에서 정적 컨텐츠 서버를 설정하기 위해 추가 Microsoft 라이센스를 지불 할 필요가 없다는 것입니다.

도움이 되었기를 바랍니다.

위에서 언급했듯이 "허용 된"솔루션은 재분석 지점에서 실패하지만 사람들은 여전히 ​​그것을 마크 업 (???)합니다. 기능을 올바르게 복제하는 훨씬 짧은 솔루션이 있습니다.

public static void rmdir(string target, bool recursive)
{
    string tfilename = Path.GetDirectoryName(target) +
        (target.Contains(Path.DirectorySeparatorChar.ToString()) ? Path.DirectorySeparatorChar.ToString() : string.Empty) +
        Path.GetRandomFileName();
    Directory.Move(target, tfilename);
    Directory.Delete(tfilename, recursive);
}

나는 나중에 언급 된 권한 사례를 처리하지 않지만 모든 의도와 목적을 위해 FAR BETTER는 원본 / 주식 Directory.Delete () 의 예상 기능 을 제공하며 코드도 훨씬 적습니다 .

'파일 시스템이 여전히 따라 잡기 때문에'(또는 MS가 깨진 기능을 제공 한 이유는 무엇이든) 이전 디렉토리가 방해가되기 때문에 안전하게 처리를 계속할 수 있습니다 .

이점으로, 대상 디렉토리가 크거나 깊으며 대기하지 않으려면 (또는 예외로 귀찮게) 마지막 행을 다음으로 바꿀 수 있습니다.

    ThreadPool.QueueUserWorkItem((o) => { Directory.Delete(tfilename, recursive); });

당신은 여전히 ​​일하는 것이 안전합니다.

이 문제는 경로 길이가 260 개보다 큰 디렉토리 (또는 서브 디렉토리)에 파일이있는 경우 Windows에 나타날 수 있습니다.

이러한 경우 \\\\?\C:\mydir대신에 삭제해야합니다 C:\mydir. 260 기호 제한에 대해서는 여기에서 읽을 수 있습니다 .

나는이 천년 기술로 해결했습니다 (스레드에서 수면을 그대로 둘 수 있습니다)

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);

응용 프로그램 (또는 다른 응용 프로그램)의 현재 디렉토리가 삭제하려는 디렉토리 인 경우, 액세스 위반 오류는 아니지만 디렉토리는 비어 있지 않습니다. 현재 디렉토리를 변경하여 자신의 응용 프로그램이 아닌지 확인하십시오. 또한 다른 프로그램 (예 : Word, excel, Total Commander 등)에서 디렉토리가 열려 있지 않은지 확인하십시오. 대부분의 프로그램은 마지막으로 열린 파일의 디렉토리로 이동하여 그 원인이됩니다.

네트워크 파일의 경우 Directory.DeleteHelper (recursive : = true)로 인해 파일 삭제 지연으로 인해 IOException이 발생할 수 있습니다.

알지 못하는 일부 스트림에 의해 열린 파일이 있다고 생각합니다. 동일한 문제가 있었고 디렉토리를 가리키는 곳에서 삭제하려는 모든 스트림을 닫아서 해결했습니다.

이 오류는 파일 또는 디렉토리가 사용중인 것으로 간주되는 경우 발생합니다. 오해의 소지가 있습니다. 탐색기 창 또는 명령 행 창이 트리의 디렉토리 또는 해당 트리의 파일을 사용하는 프로그램에 열려 있는지 확인하십시오.

메소드가 비동기적이고 다음과 같이 코딩 될 때 언급 된 문제의 가능한 인스턴스를 해결했습니다.

// 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 문 내부의 비동기 메서드에 if 문이 using 문처럼 작동하는 것처럼 보입니다.

추가 폴더 안에있는 파일을 재귀 또는 삭제하기위한 추가 방법을 만들 필요가 없습니다. 이 모든 것은 전화로 자동 수행

DirectoryInfo.Delete ();

자세한 내용은 여기 입니다.

이와 같은 것이 꽤 잘 작동합니다.

  var directoryInfo = new DirectoryInfo("My directory path");
    // Delete all files from app data directory.

    foreach (var subDirectory in directoryInfo.GetDirectories())
    {
          subDirectory.Delete(true);// true set recursive paramter, when it is true delete sub file and sub folder with files too
    }

메서드를 삭제하는 변수로 true를 전달 하면 파일이있는 하위 파일과 하위 폴더도 삭제됩니다.

위의 답변 중 어느 것도 나를 위해 일하지 않았습니다. 내 자신의 앱 사용이DirectoryInfo대상 디렉토리에서 하여 잠긴 상태로 유지 된 .

가비지 수집을 강제 실행하면 문제가 해결 된 것으로 보이나 즉시 해결되지는 않습니다. 필요한 경우 몇 차례 삭제를 시도합니다.

노트 Directory.Exists는 예외 후에 사라질 수있다. 삭제가 지연된 이유를 모르겠습니다 (Windows 7 SP1).

        for (int attempts = 0; attempts < 10; attempts++)
        {
            try
            {
                if (Directory.Exists(folder))
                {
                    Directory.Delete(folder, true);
                }
                return;
            }
            catch (IOException e)
            {
                GC.Collect();
                Thread.Sleep(1000);
            }
        }

        throw new Exception("Failed to remove folder.");

두 번째 매개 변수에 true를 추가하십시오.

Directory.Delete(path, true);

모두 제거됩니다.