ฉันใช้. 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)
    ...

ฉันไม่แปลกใจที่บางครั้งวิธีการโยน แต่ฉันประหลาดใจที่ได้รับข้อความนี้เมื่อเรียกซ้ำเป็นจริง (ฉันรู้ว่าไดเรกทอรีไม่ว่างเปล่า)

มีเหตุผลที่ฉันเห็นสิ่งนี้แทน 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เปิดไดเรกทอรีใน Explorer bจะถูกลบ แต่คุณจะได้รับข้อผิดพลาด 'ไดเรกทอรีไม่ว่าง' aแม้ว่ามันจะว่างเปล่าเมื่อคุณไปดู ไดเรกทอรีปัจจุบันของโปรแกรมใด ๆ (รวมทั้ง Explorer) ยังคงมีการจัดการไปยังไดเรกทอรี เมื่อคุณเรียกDirectory.Delete(true)มันลบจากด้านล่างขึ้น: แล้วb aหากbเปิดอยู่ใน Explorer Explorer จะตรวจจับการลบbเปลี่ยนไดเรกทอรีขึ้นcd ..และล้างจุดจับเปิด เนื่องจากระบบไฟล์ทำงานแบบอะซิงโครนัสการDirectory.Deleteดำเนินการล้มเหลวเนื่องจากข้อขัดแย้งกับ Explorer

โซลูชันที่ไม่สมบูรณ์

ฉันโพสต์วิธีแก้ไขปัญหาต่อไปนี้โดยเริ่มต้นด้วยแนวคิดของการขัดจังหวะเธรดปัจจุบันเพื่อให้เวลา Explorer ปล่อยตัวจัดการไดเรกทอรี

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

แต่นี้จะทำงานเฉพาะถ้าไดเรกทอรีเปิดเป็นทันทีลูกของไดเรกทอรีที่คุณกำลังลบ หากa\b\c\dมีการเปิดใน Explorer และคุณใช้เกี่ยวกับเรื่องนี้aเทคนิคนี้จะล้มเหลวหลังจากลบและdc

ทางออกที่ค่อนข้างดีกว่า

วิธีนี้จะจัดการกับการลบโครงสร้างไดเรกทอรีที่ลึกแม้ว่าหนึ่งในไดเรกทอรีระดับล่างเปิดใน Explorer

/// <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ที่สามารถเกิดขึ้นได้ตลอดทาง ไม่ชัดเจนว่าความพยายามในการลบครั้งแรกนั้นเป็นการปูทางไปสู่ความสำเร็จครั้งที่สองหรือไม่หรือถ้าเป็นเพียงการหน่วงเวลาตามคำแนะนำจากการขว้างปา / จับข้อยกเว้นที่อนุญาตให้ระบบไฟล์ติดตาม

คุณอาจสามารถลดจำนวนข้อยกเว้นที่ถูกโยนและถูกจับได้ภายใต้เงื่อนไขทั่วไปโดยการเพิ่ม a Thread.Sleep(0)ที่จุดเริ่มต้นของtryบล็อก นอกจากนี้ยังมีความเสี่ยงที่ภายใต้ภาระของระบบจำนวนมากคุณสามารถบินผ่านทั้งDirectory.Deleteความพยายามและความล้มเหลว พิจารณาโซลูชันนี้เป็นจุดเริ่มต้นสำหรับการลบแบบเรียกซ้ำที่มีประสิทธิภาพมากขึ้น

คำตอบทั่วไป

วิธีนี้แก้ไขปัญหาเฉพาะของการโต้ตอบกับ Windows Explorer หากคุณต้องการการลบแบบแข็ง ๆ สิ่งหนึ่งที่ต้องจำไว้ก็คือทุกสิ่ง (ตัวสแกนไวรัสหรืออะไรก็ตาม) อาจมีจุดเปิดแบบเปิดสำหรับสิ่งที่คุณพยายามลบได้ตลอดเวลา ดังนั้นคุณต้องลองอีกครั้งในภายหลัง จำนวนเท่าใดในภายหลังและจำนวนครั้งที่คุณลองขึ้นอยู่กับความสำคัญของวัตถุที่ถูกลบ ในฐานะที่เป็นMSDN บ่งชี้ ,

รหัสการวนซ้ำไฟล์ที่แข็งแกร่งต้องคำนึงถึงความซับซ้อนหลายประการของระบบไฟล์

ข้อความบริสุทธิ์นี้มาพร้อมกับลิงก์ไปยังเอกสารอ้างอิง NTFS เท่านั้นควรทำให้เส้นขนของคุณดูโดดเด่นขึ้น

( แก้ไข : เยอะมากคำตอบนี้มี แต่โซลูชันแรกที่ไม่สมบูรณ์เท่านั้น)

ก่อนดำเนินการต่อให้ตรวจสอบสาเหตุต่อไปนี้ที่อยู่ภายใต้การควบคุมของคุณ:

• โฟลเดอร์ถูกตั้งค่าเป็นไดเรกทอรีปัจจุบันของกระบวนการของคุณหรือไม่? ถ้าใช่เปลี่ยนเป็นอย่างอื่นก่อน
• คุณเปิดไฟล์ (หรือโหลด DLL) จากโฟลเดอร์นั้นหรือไม่? (และลืมปิด / ยกเลิกการโหลด)

มิฉะนั้นให้ตรวจสอบเหตุผลที่ถูกต้องต่อไปนี้นอกการควบคุมของคุณ:

• มีไฟล์ที่ทำเครื่องหมายว่าอ่านอย่างเดียวในโฟลเดอร์นั้น
• คุณไม่ได้รับอนุญาตให้ลบไฟล์เหล่านั้นบางไฟล์
• ไฟล์หรือโฟลเดอร์ย่อยเปิดใน Explorer หรือแอปอื่น

หากข้อใดข้อหนึ่งข้างต้นเป็นปัญหาคุณควรเข้าใจว่าเหตุใดจึงเกิดขึ้นก่อนที่จะพยายามปรับปรุงรหัสการลบของคุณ แอปของคุณควรลบไฟล์แบบอ่านอย่างเดียวหรือไม่สามารถเข้าถึงได้ ใครทำเครื่องหมายไว้อย่างนั้นและทำไม?

เมื่อคุณยกเลิกเหตุผลข้างต้นแล้วยังมีความเป็นไปได้ที่จะเกิดความล้มเหลวปลอม การลบจะล้มเหลวหากใครถือที่จับกับไฟล์หรือโฟลเดอร์ใด ๆ ที่ถูกลบและมีสาเหตุหลายประการว่าทำไมบางคนอาจระบุโฟลเดอร์หรืออ่านไฟล์:

• ค้นหาดัชนี
• ป้องกันไวรัส
• ซอฟต์แวร์สำรองข้อมูล

วิธีการทั่วไปในการจัดการกับความล้มเหลวแบบลวงตาคือลองหลาย ๆ ครั้งระหว่างหยุดชั่วคราว เห็นได้ชัดว่าคุณไม่ต้องการที่จะพยายามตลอดไปดังนั้นคุณควรยอมแพ้หลังจากพยายามหลายครั้งและโยนข้อยกเว้นหรือเพิกเฉยต่อข้อผิดพลาด แบบนี้:

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. เป็นโฟลเดอร์ข้อมูลภายในฉันไม่คิดว่ามันจะเปิดใน explorer อย่างน้อยฉันก็ไม่รู้สึกว่าจำเป็นต้องจัดการเคสเป็นพิเศษ (เช่นฉันจัดการกับเคสนั้นได้ดีผ่านการสนับสนุน)

4. หากความพยายามทั้งหมดล้มเหลวฉันเลือกที่จะไม่สนใจข้อผิดพลาด กรณีที่เลวร้ายที่สุดแอพไม่สามารถคลายทรัพยากรใหม่บางอันเกิดปัญหาและแจ้งให้ผู้ใช้ติดต่อฝ่ายสนับสนุนซึ่งเป็นที่ยอมรับของฉันตราบใดที่มันไม่ได้เกิดขึ้นบ่อย หรือหากแอพไม่ผิดพลาดก็จะทิ้งข้อมูลเก่าไว้ซึ่งเป็นที่ยอมรับได้อีกครั้ง

5. ฉันเลือกที่จะ จำกัด การลองใหม่เป็น 500ms (50 * 10) นี่เป็นขีด จำกัด โดยพลการซึ่งใช้งานได้จริง ฉันต้องการให้ขีด จำกัด สั้นพอที่ผู้ใช้จะไม่ฆ่าแอปโดยคิดว่ามันหยุดตอบสนอง ในทางตรงกันข้ามครึ่งวินาทีนั้นมีเวลาอีกมากที่ผู้กระทำผิดจะประมวลผลโฟลเดอร์ของฉันให้เสร็จ ตัดสินจากคำตอบ SO อื่น ๆ ซึ่งบางครั้งพบว่าSleep(0)เป็นที่ยอมรับได้ แต่ผู้ใช้เพียงไม่กี่รายจะได้รับประสบการณ์มากกว่าการลองใหม่เพียงครั้งเดียว

6. ฉันลองใหม่ทุก ๆ 50ms ซึ่งเป็นอีกจำนวนหนึ่งโดยพลการ ฉันรู้สึกว่าหากไฟล์กำลังถูกประมวลผล (ทำดัชนีตรวจสอบแล้ว) เมื่อฉันพยายามลบมัน 50ms เป็นเวลาที่เหมาะสมในการคาดหวังว่าการประมวลผลจะเสร็จสมบูรณ์ในกรณีของฉัน นอกจากนี้ 50ms มีขนาดเล็กพอที่จะไม่ทำให้เกิดการชะลอตัวที่เห็นได้ชัด อีกครั้งSleep(0)ดูเหมือนจะเพียงพอในหลายกรณีดังนั้นเราไม่ต้องการล่าช้ามากเกินไป

7. รหัสจะลองใช้กับข้อยกเว้น IO ใด ๆ ปกติฉันไม่คาดหวังว่าจะมีข้อยกเว้นใด ๆ ในการเข้าถึง% LocalAppData% ดังนั้นฉันเลือกความเรียบง่ายและยอมรับความเสี่ยงของการล่าช้า 500ms ในกรณีที่มีข้อยกเว้นทางกฎหมายเกิดขึ้น ฉันไม่ต้องการที่จะหาวิธีในการตรวจสอบข้อยกเว้นที่แน่นอนที่ฉันต้องการลองใหม่อีกครั้ง

คำตอบ Async ที่ทันสมัย

คำตอบที่ยอมรับนั้นผิดธรรมดามันอาจใช้ได้กับบางคนเพราะเวลาที่ใช้ในการรับไฟล์จากดิสก์ทำให้ทุกอย่างถูกล็อกไฟล์ ความจริงก็คือสิ่งนี้เกิดขึ้นเพราะไฟล์ถูกล็อคโดยกระบวนการ / สตรีม / แอ็คชันอื่น ๆ คำตอบอื่น ๆ ใช้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

ลบไดเร็กทอรีว่างและหากระบุไดเร็กทอรีย่อยและไฟล์ใด ๆ ในไดเร็กทอรี

ฉันมีปัญหาเดียวกันภายใต้ Delphi และผลลัพธ์สุดท้ายก็คือแอปพลิเคชันของฉันถูกล็อคไดเรกทอรีที่ฉันต้องการลบ อย่างใดไดเรกทอรีถูกล็อคเมื่อฉันเขียนมัน (บางไฟล์ชั่วคราว)

อันดับที่ 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' ถูกประทับตราว่าถูกลบ แต่การลบยังไม่ได้กระทำในระบบ ระบบตอบกลับงานเสร็จแล้วในขณะที่ในความเป็นจริงมันยังคงดำเนินการอยู่ ระบบอาจรอให้ file explorer มีโฟกัสที่ไดเร็กทอรีพาเรนต์เพื่อคอมมิตการลบ

ถ้าคุณดูรหัสแหล่งที่มาของฟังก์ชันลบ ( 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

ฉันมีปัญหาเกี่ยวกับการอนุญาตแปลก ๆ เหล่านี้ในการลบไดเรกทอรีโปรไฟล์ผู้ใช้ (ใน C: \ Documents and Settings) แม้ว่าจะสามารถทำได้ในเชลล์ Explorer

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

มันไม่มีเหตุผลสำหรับฉันในการดำเนินการ "ไฟล์" ในไดเรกทอรี แต่ฉันรู้ว่ามันใช้งานได้และนั่นก็เพียงพอแล้วสำหรับฉัน!

คำตอบนี้จะขึ้นอยู่กับตาม: https://stackoverflow.com/a/1703799/184528 ความแตกต่างกับรหัสของฉันคือเราเพียงเรียกคืนการลบไดเรกทอรีย่อยและไฟล์จำนวนมากเมื่อจำเป็นต้องเรียก Directory.Delete ล้มเหลวในความพยายามครั้งแรก (ซึ่งอาจเกิดขึ้นเนื่องจาก windows explorer ดูที่ไดเรกทอรี)

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

เป็นไปได้หรือไม่ที่คุณมีสภาวะการแย่งชิงที่เธรดหรือกระบวนการอื่นกำลังเพิ่มไฟล์ในไดเรกทอรี

ลำดับจะเป็น:

กระบวนการ Deleter A:

1. ล้างไดเรกทอรี
2. ลบไดเรกทอรี (ว่างเปล่า)

หากมีคนอื่นเพิ่มไฟล์ระหว่าง 1 และ 2 ดังนั้นอาจ 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);
        }
    }

รหัสนี้มีความล่าช้าเล็กน้อยซึ่งไม่สำคัญสำหรับแอปพลิเคชันของฉัน แต่ระวังความล่าช้าอาจเป็นปัญหาสำหรับคุณหากคุณมีไดเรกทอรีย่อยจำนวนมากในไดเรกทอรีที่คุณต้องการลบ

การลบไดเรกทอรีซ้ำที่ไม่ลบไฟล์นั้นไม่คาดคิด การแก้ไขของฉันสำหรับที่:

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

ผมมีประสบการณ์กรณีที่ช่วยนี้ แต่โดยทั่วไป Directory.Delete ลบไฟล์ภายในไดเรกทอรีเมื่อลบ recursive เป็นเอกสารใน MSDN

บางครั้งฉันพบกับพฤติกรรมที่ผิดปกติเช่นนี้ในฐานะผู้ใช้ Windows Explorer: บางครั้งฉันไม่สามารถลบโฟลเดอร์ได้ (บางครั้งฉันคิดว่าข้อความไร้สาระคือ "การเข้าถึงถูกปฏิเสธ") แต่เมื่อฉันเจาะลึกลงและลบรายการที่ต่ำกว่า รายการเช่นกัน ดังนั้นฉันเดารหัสข้างต้นเกี่ยวกับความผิดปกติของระบบปฏิบัติการ - ไม่ใช่ปัญหาไลบรารีคลาสพื้นฐาน

ไดเรกทอรีหรือไฟล์ในนั้นถูกล็อคและไม่สามารถลบได้ ค้นหาผู้ร้ายที่ล็อคและดูว่าคุณสามารถกำจัดมันได้หรือไม่

ปรากฏว่าการเลือกพา ธ หรือโฟลเดอร์ย่อยใน Windows Explorer นั้นเพียงพอที่จะบล็อกการเรียกใช้งานไดเรกทอรีเดียวลบ (เส้นทางจริง) แล้วโยน IOException ตามที่อธิบายไว้ข้างต้นและตายแทนการบูต Windows Explorer ไปยังโฟลเดอร์หลักและดำเนินการตาม ที่คาดหวัง

ฉันมีปัญหานี้ในวันนี้ มันเกิดขึ้นเพราะฉันเปิด windows explorer ไปยังไดเรกทอรีที่พยายามจะลบทำให้การเรียกซ้ำเกิดความล้มเหลวและทำให้ IOException ตรวจสอบให้แน่ใจว่าไม่มีหมายเลขอ้างอิงที่เปิดไปยังไดเรกทอรี

นอกจากนี้ MSDN ยังชัดเจนว่าคุณไม่ต้องเขียนการเขียนซ้ำของคุณเอง: http://msdn.microsoft.com/en-us/library/fxeahc5f.aspx

ฉันมีปัญหาเดียวกันกับ Windows Workflow Foundation บน build server ที่มี TFS2012 ภายในเวิร์กโฟลว์ที่เรียกว่า Directory.Delete () พร้อมกับตั้งค่าสถานะแบบเรียกซ้ำเป็นจริง ดูเหมือนจะเกี่ยวข้องกับเครือข่ายในกรณีของเรา

เรากำลังลบโฟลเดอร์ไบนารีดร็อปบนเครือข่ายที่ใช้ร่วมกันก่อนที่จะสร้างใหม่และเติมข้อมูลซ้ำด้วยไบนารีล่าสุด การสร้างอื่น ๆ จะล้มเหลว เมื่อเปิดโฟลเดอร์ดรอปหลังจากบิลด์ที่ล้มเหลวโฟลเดอร์ว่างเปล่าซึ่งบ่งชี้ว่าการเรียกใช้ Directory.Delete () ทุกด้านสำเร็จยกเว้นการลบไดเรกทอรีจริง

ปัญหาดูเหมือนจะเกิดจากลักษณะของการสื่อสารไฟล์เครือข่ายแบบอะซิงโครนัส เซิร์ฟเวอร์บิลด์บอกให้ไฟล์เซิร์ฟเวอร์ลบไฟล์ทั้งหมดและไฟล์เซิร์ฟเวอร์รายงานว่ามีไฟล์แม้ว่ามันจะยังไม่เสร็จสิ้นก็ตาม จากนั้นบิลด์เซิร์ฟเวอร์ขอให้ลบไดเรกทอรีและไฟล์เซิร์ฟเวอร์ปฏิเสธการร้องขอเนื่องจากการลบไฟล์ไม่เสร็จสิ้น

โซลูชันที่เป็นไปได้สองแบบในกรณีของเรา:

• สร้างการลบซ้ำในรหัสของเราเองด้วยความล่าช้าและการตรวจสอบระหว่างแต่ละขั้นตอน
• ลองใหม่อีกครั้งถึง X ครั้งหลังจาก IOException ทำให้เกิดความล่าช้าก่อนที่จะลองอีกครั้ง

วิธีหลังนั้นรวดเร็วและสกปรก แต่ดูเหมือนว่าจะทำเคล็ดลับ

นี่เป็นเพราะ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 เพียงพอที่จะรู้เกี่ยวกับการลบและปิดแอปของคุณ ในขณะเดียวกันไดเรกทอรีหลักของคุณยังไม่ถูกลบ นี่คือเหตุการณ์จากบันทึก:

Delete() ไม่ทำงานให้เสร็จและเนื่องจากแอปปิดตัวลงจึงทำให้เกิดข้อยกเว้น:

เมื่อคุณไม่มีโฟลเดอร์ย่อยใด ๆในโฟลเดอร์ที่คุณกำลังลบ Delete () เพียงแค่ลบไฟล์ทั้งหมดและโฟลเดอร์นั้นแอปก็เริ่มต้นใหม่ด้วยเช่นกัน แต่คุณไม่ได้รับข้อยกเว้นใด ๆเนื่องจากการรีสตาร์ทแอพจะไม่ขัดจังหวะอะไรเลย แต่คุณจะสูญเสียเซสชันที่อยู่ระหว่างดำเนินการแอพไม่ตอบสนองต่อคำขอเมื่อรีสตาร์ทเป็นต้น

เกิดอะไรขึ้น

มีวิธีแก้ไขปัญหาบางอย่างและปรับแต่งเพื่อปิดการใช้งานพฤติกรรมนี้, Junction Directory , การปิด FCN ด้วย Registry , การหยุด FileChangesMonitor โดยใช้ Reflection (เนื่องจากไม่มีวิธีการเปิดเผย)แต่พวกเขาทั้งหมดดูเหมือนจะไม่ถูกต้องเพราะ FCN มีไว้สำหรับ เหตุผล. มันเป็นเรื่องที่มองหาหลังจากที่โครงสร้างของแอปของคุณซึ่งไม่เป็นโครงสร้างของข้อมูลของคุณ คำตอบสั้น ๆ คือ: วางโฟลเดอร์ที่คุณต้องการลบนอกแอพของคุณ FileChangesMonitor จะไม่ได้รับการแจ้งเตือนและแอพของคุณจะไม่ถูกรีสตาร์ททุกครั้ง คุณจะไม่มีข้อยกเว้น ในการทำให้มองเห็นได้จากเว็บมีสองวิธี:

1. สร้างตัวควบคุมที่จัดการสายเรียกเข้าจากนั้นให้บริการไฟล์กลับโดยอ่านจากโฟลเดอร์นอกแอพ (นอก wwwroot)

2. หากโครงการของคุณมีขนาดใหญ่และประสิทธิภาพเป็นสิ่งสำคัญที่สุดให้ตั้งค่าเว็บเซิร์ฟเวอร์ขนาดเล็กและรวดเร็วแยกต่างหากสำหรับการให้บริการเนื้อหาคงที่ ดังนั้นคุณจะปล่อยให้ IIS งานเฉพาะของเขา มันอาจจะอยู่ในเครื่องเดียวกัน (พังพอนสำหรับ Windows) หรือเครื่องอื่น (nginx สำหรับ Linux) ข่าวดีก็คือคุณไม่ต้องจ่ายค่าลิขสิทธิ์ Microsoft เพิ่มเติมเพื่อตั้งค่าเซิร์ฟเวอร์เนื้อหาแบบคงที่ใน linux

หวังว่านี่จะช่วยได้

ดังที่ได้กล่าวไว้ข้างต้นโซลูชัน "ยอมรับ" ล้มเหลวในจุดแยกวิเคราะห์ใหม่ - แต่คนยังคงทำเครื่องหมาย (???) มีวิธีแก้ปัญหาที่สั้นกว่ามากซึ่งจำลองฟังก์ชันการทำงานอย่างถูกต้อง:

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

ฉันรู้ว่าไม่ได้จัดการกรณีการอนุญาตที่กล่าวถึงในภายหลัง แต่สำหรับ Intent และวัตถุประสงค์ทั้งหมด FAR BETTER จะให้การทำงานที่คาดหวังของไดเรกทอรีต้นฉบับ / หุ้น Delete () - และมีรหัสน้อยเกินไปกัน

คุณสามารถดำเนินการต่อได้อย่างปลอดภัยเพราะ dir เก่าจะออกนอกทาง ... แม้ว่าจะไม่หายไปเพราะ 'ระบบไฟล์ยังคงติดตามอยู่' (หรือข้อแก้ตัวใด ๆ ที่ MS มอบให้สำหรับการทำงานที่ไม่สมบูรณ์)ข้ออ้างให้สำหรับการให้บริการฟังก์ชั่นหัก)

ประโยชน์ถ้าคุณรู้ว่าไดเรกทอรีเป้าหมายของคุณมีขนาดใหญ่ / ลึกและไม่ต้องการรอ (หรือรำคาญกับข้อยกเว้น) บรรทัดสุดท้ายจะถูกแทนที่ด้วย:

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

คุณยังปลอดภัยที่จะทำงานต่อไป

ปัญหานี้สามารถปรากฏบน Windows เมื่อมีไฟล์ในไดเรกทอรี (หรือในไดเรกทอรีย่อยใด ๆ ) ที่มีความยาวเส้นทางมากกว่า 260 สัญลักษณ์

ในกรณีเช่นนี้คุณจะต้องลบแทน\\\\?\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 เป็นต้น) โปรแกรมส่วนใหญ่จะ cd ไปยังไดเรกทอรีของไฟล์ล่าสุดที่เปิดซึ่งจะทำให้เกิด

ในกรณีของไฟล์เครือข่าย Directory.DeleteHelper (เรียกซ้ำ: = จริง) อาจทำให้ IOException ซึ่งเกิดจากความล่าช้าในการลบไฟล์

ฉันคิดว่ามีไฟล์ที่เปิดโดยสตรีมบางรายการที่คุณไม่ทราบว่าฉันมีปัญหาเดียวกันและแก้ไขได้โดยปิดสตรีมทั้งหมดที่ชี้ไปยังไดเรกทอรีที่ฉันต้องการลบ

ข้อผิดพลาดนี้เกิดขึ้นหากไฟล์หรือไดเรกทอรีใด ๆ ถูกพิจารณาว่าใช้งานไม่ได้ มันเป็นข้อผิดพลาดที่ทำให้เข้าใจผิด ตรวจสอบดูว่าคุณมี windows explorer หรือ windows บรรทัดคำสั่งเปิดอยู่ในไดเรกทอรีใด ๆ ในแผนผังหรือโปรแกรมที่ใช้ไฟล์ในแผนผังนั้น

ฉันแก้ไขอินสแตนซ์ที่เป็นไปได้หนึ่งรายการของปัญหาที่ระบุไว้เมื่อเมธอดเป็น async และโค้ดแบบนี้:

// 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 ที่ทำหน้าที่เหมือนกับการใช้คำสั่ง

คุณไม่ต้องสร้างและวิธีพิเศษสำหรับการเรียกซ้ำหรือลบไฟล์ภายในโฟลเดอร์พิเศษ ทั้งหมดนี้ทำโดยอัตโนมัติด้วยการโทร

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
    }

ผ่านจริงเป็นตัวแปรเพื่อลบวิธีการจะลบไฟล์ย่อยและโฟลเดอร์ย่อยที่มีไฟล์ด้วย

คำตอบข้างต้นไม่เหมาะกับฉัน ดูเหมือนว่าการใช้งานแอปของฉัน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.");

เพิ่มจริงในพารามิเตอร์ที่สอง

Directory.Delete(path, true);

มันจะลบทั้งหมด