การลบโฟลเดอร์แบบเรียกซ้ำแบบไม่สิ้นสุด

อย่างใดอย่างหนึ่งกล่อง Server 2008 (ไม่ใช่ R2) รุ่นเก่าของเราได้พัฒนาโฟลเดอร์ที่มีการเรียกซ้ำที่ไม่สิ้นสุด นี่คือการเล่น havock กับการสำรองข้อมูลของเราเนื่องจากตัวแทนการสำรองข้อมูลพยายามที่จะย่อหย่อนลงในโฟลเดอร์และไม่ส่งคืน

โครงสร้างโฟลเดอร์มีลักษณะดังนี้:

C:\Storage\Folder1
C:\Storage\Folder1\Folder1
C:\Storage\Folder1\Folder1\Folder1
C:\Storage\Folder1\Folder1\Folder1\Folder1

... และต่อไป มันเหมือนกับหนึ่งในชุด Mandelbrot ที่เราเคยเล่นด้วยในยุค 90

ฉันได้ลองแล้ว:

• ลบออกจาก Explorer ใช่ฉันเป็นคนมองโลกในแง่ดี
• RMDIR C:\Storage\Folder1 /Q/S - สิ่งนี้จะกลับมา The directory is not empty
• ROBOCOPY C:\temp\EmptyDirectory C:\Storage\Folder1 /PURGE - สิ่งนี้จะหมุนผ่านโฟลเดอร์เป็นเวลาสองสามนาทีก่อนที่ robocopy.exe จะล่ม

ใครช่วยแนะนำวิธีฆ่าโฟลเดอร์นี้ให้ดีหรือไม่?

ขอบคุณทุกคนสำหรับคำแนะนำที่เป็นประโยชน์

หลงทางไปในดินแดน StackOverflow ฉันได้แก้ไขปัญหาโดยการเคาะโค้ด C # นี้ขึ้น จะใช้ไลบรารีDelimon.Win32.IOที่เน้นปัญหาการเข้าถึงเส้นทางไฟล์ยาวโดยเฉพาะ

ในกรณีที่สามารถช่วยคนอื่นได้นี่คือรหัส - ผ่านระดับการเรียกซ้ำ ~ 1600 ระดับที่ฉันติดอยู่และใช้เวลาประมาณ 20 นาทีในการลบออกทั้งหมด

using System;
using Delimon.Win32.IO;

namespace ConsoleApplication1
{
    class Program
    {
        private static int level;
        static void Main(string[] args)
        {
            // Call the method to delete the directory structure
            RecursiveDelete(new DirectoryInfo(@"\\server\\c$\\storage\\folder1"));
        }

        // This deletes a particular folder, and recurses back to itself if it finds any subfolders
        public static void RecursiveDelete(DirectoryInfo Dir)
        {
            level++;
            Console.WriteLine("Now at level " +level);
            if (!Dir.Exists)
                return;

            // In any subdirectory ...
            foreach (var dir in Dir.GetDirectories())
            {
                // Call this method again, starting at the subdirectory
                RecursiveDelete(dir);
            }

            // Finally, delete the directory, and any files below it
            Dir.Delete(true);
            Console.WriteLine("Deleting directory at level " + level);
            level--;
        }
    }
}

อาจเป็นจุดเชื่อมต่อแบบเรียกซ้ำ สิ่งดังกล่าวสามารถสร้างขึ้นด้วยjunctionไฟล์และดิสก์ยูทิลิตี้จากSysinternals

mkdir c:\Hello
junction c:\Hello\Hello c:\Hello

และในตอนนี้คุณสามารถลดระดับลง c: \ Hello \ Hello \ Hello .... (จนถึง MAX_PATH ถึง 260 ตัวอักษรสำหรับคำสั่งส่วนใหญ่ แต่ 32,767 ตัวอักษรสำหรับฟังก์ชั่น Windows API บางตัว)

รายการไดเรกทอรีแสดงว่าเป็นทางแยก:

C:\>dir c:\hello
 Volume in drive C is DR1
 Volume Serial Number is 993E-B99C

 Directory of c:\hello

12/02/2015  08:18 AM    <DIR>          .
12/02/2015  08:18 AM    <DIR>          ..
12/02/2015  08:18 AM    <JUNCTION>     hello [\??\c:\hello]
               0 File(s)              0 bytes
               3 Dir(s)  461,591,506,944 bytes free

C:\>

ในการลบให้ใช้ยูทิลิตี junction:

junction -d c:\Hello\Hello

ไม่ใช่คำตอบ แต่ฉันมีตัวแทนไม่เพียงพอสำหรับความคิดเห็น

ฉันเคยแก้ไขปัญหานี้ในดิสก์ FAT16 ขนาด 500MB ที่มีขนาดใหญ่มากในระบบ MS-DOS ฉันใช้ DOS debug เพื่อถ่ายโอนข้อมูลด้วยตนเองและแยกวิเคราะห์ผ่านตารางไดเรกทอรี จากนั้นฉันพลิกหนึ่งบิตเพื่อทำเครื่องหมายไดเรกทอรีซ้ำว่าถูกลบ สำเนา Dettman และ Wyatt ของฉัน 'DOS Programmers' Reference 'แสดงให้ฉันเห็นวิธี

ฉันภูมิใจในสิ่งนี้อย่างมาก ฉันจะประหลาดใจและหวาดกลัวหากมีเครื่องมือที่ใช้งานทั่วไปที่มีพลังเหนือปริมาณ FAT32 หรือ NTFS ชีวิตเรียบง่ายขึ้นในตอนนั้น

Java ยังสามารถจัดการกับเส้นทางไฟล์ยาว และมันสามารถทำมันได้เร็วขึ้นมากเช่นกัน รหัสนี้ (ซึ่งฉันคัดลอกมาจากเอกสารประกอบ Java API) จะลบโครงสร้างไดเรกทอรีระดับลึก 1600 ในเวลาประมาณ 1 วินาที (ภายใต้ Windows 7, Java 8.0) และไม่มีความเสี่ยงของการล้นสแต็กเนื่องจากไม่ได้ใช้การสอบถามซ้ำ

import java.nio.file.*;
import java.nio.file.attribute.*;
import java.io.*;

public class DeleteDir {

  static void deleteDirRecur(Path dir) throws IOException {
    Files.walkFileTree(dir, new SimpleFileVisitor<Path>() {
         @Override
         public FileVisitResult visitFile(Path file, BasicFileAttributes attrs)
             throws IOException
         {
             Files.delete(file);
             return FileVisitResult.CONTINUE;
         }
         @Override
         public FileVisitResult postVisitDirectory(Path dir, IOException e)
             throws IOException
         {
             if (e == null) {
                 Files.delete(dir);
                 return FileVisitResult.CONTINUE;
             } else {
                 throw e;
             }
         }
     });
  }

  public static void main(String[] args) throws IOException {
    deleteDirRecur(Paths.get("C:/Storage/Folder1"));
  }
}

คุณไม่จำเป็นต้อง pathnames ยาวถ้าคุณลงในไดเรกทอรีและใช้เพียงเส้นทางเทียบกับchdirrmdir

หรือถ้าคุณติดตั้งเชลล์ POSIX หรือพอร์ตนี้ไปยัง DOS ที่เทียบเท่า:

# untested code, didn't bother actually testing since the OP already solved the problem.

while [ -d Folder1 ]; do
    mv Folder1/Folder1/Folder1/Folder1  tmp # repeat more times to work in larger batches
    rm -r Folder1     # remove the first several levels remaining after moving the main tree out
    # then repeat to end up with the remaining big tree under the original name
    mv tmp/Folder1/Folder1/.../Folder1 Folder1 
    rm -r tmp
done

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

สิ่งนี้จะช่วยหลีกเลี่ยงค่าใช้จ่าย CPU ของโซลูชันของ KenD ซึ่งบังคับให้ OS สำรวจต้นไม้จากด้านบนไปยังnระดับ th ทุกครั้งที่มีการเพิ่มระดับใหม่การตรวจสอบสิทธิ์เป็นต้นดังนั้นจึงมีsum(1, n) = n * (n-1) / 2 = O(n^2)ความซับซ้อนของเวลา โซลูชั่นที่ตัดชิ้นส่วนจากจุดเริ่มต้นของลูกโซ่ควรเป็นO(n)เว้นแต่ว่า Windows จำเป็นต้องสำรวจทรีเมื่อทำการเปลี่ยนชื่อไดเรกทอรีหลัก (Linux / Unix ไม่ได้) วิธีแก้ปัญหาที่chdirถึงด้านล่างของต้นไม้และใช้เส้นทางสัมพัทธ์จากที่นั่นลบไดเรกทอรีที่พวกเขาchdirสำรองควรเป็นO(n)สมมติว่าระบบปฏิบัติการไม่จำเป็นต้องตรวจสอบทั้งหมดของคุณ พาเรนต์ไดเร็กทอรีทุกการเรียกของระบบเมื่อคุณทำสิ่งต่าง ๆ ขณะที่อยู่ใน CD

find Folder1 -depth -execdir rmdir {} +จะเรียกใช้ rmdir ขณะที่ซีดีไปยังไดเรกทอรีที่ลึกที่สุด หรือที่จริงหาของตัวเลือกที่ทำงานบนไดเรกทอรีและหมายถึง-delete -depthดังนั้นfind Folder1 -deleteควรทำสิ่งเดียวกันแน่นอน แต่เร็วกว่า ใช่ GNU พบบนลินุกซ์ให้สิ้นซากโดยการสแกนไดเรกทอรี CDing ไดเรกทอรีย่อยกับทางญาติแล้วกับทางญาติแล้วrmdir chdir("..")มันไม่สแกนไดเรกทอรีในขณะที่ขึ้นมาดังนั้นมันจะกินO(n)แรม

นั่นคือจริงๆประมาณ: straceแสดงให้เห็นว่ามันใช้จริงunlinkat(AT_FDCWD, "tmp", AT_REMOVEDIR), open("..", O_DIRECTORY|...)และfchdir(the fd from opening the directory)มีพวงของfstatสายผสมในเกินไป แต่เอฟเฟกต์จะเหมือนกันถ้าทรีไดเรกทอรีไม่ได้รับการแก้ไขขณะที่ find กำลังทำงาน

แก้ไข: เพียงเพื่อความบันเทิงฉันได้ลองทำสิ่งนี้บน GNU / Linux (Ubuntu 14.10 บน CPU Core2Duo รุ่นแรก 2.4GHz บนระบบไฟล์ XFS บนไดรฟ์ WD 2.5TB Green Power (WD25EZRS))

time mkdir -p $(perl -e 'print "annoyingfoldername/" x 2000, "\n"')

real    0m1.141s
user    0m0.005s
sys     0m0.052s

find annoyingfoldername/ | wc
   2000    2000 38019001  # 2k lines / 2k words / 38M characters of text


ll -R annoyingfoldername
... eventually
ls: cannot access ./annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername/annoyingfoldername: File name too long
total 0
?????????? ? ? ? ?            ? annoyingfoldername

time find annoyingfoldername -delete

real    0m0.054s
user    0m0.004s
sys     0m0.049s

# about the same for normal rm -r,
# which also didn't fail due to long path names

(mkdir -p สร้างไดเรกทอรีและส่วนประกอบของพา ธ ที่หายไป)

ใช่ 0.05 วินาทีจริงสำหรับ 2k rmdir ops xfs ค่อนข้างดีในการรวบรวมการดำเนินการเมตาดาต้าเข้าด้วยกันในบันทึกประจำวันเนื่องจากพวกเขาแก้ไข meta data ops ช้าเหมือนเมื่อ 10 ปีที่แล้ว

บน ext4 สร้างใช้เวลา 0m0.279s ลบโดยที่ find ยังใช้เวลา 0m0.074s

ฉันพบปัญหาเดียวกันกับระเบียบโฟลเดอร์ที่มีความลึกของไดเรกทอรีมากกว่า 5,000 รายการที่แอปพลิเคชัน Java บางตัวทำและฉันเขียนโปรแกรมที่จะช่วยคุณลบโฟลเดอร์นี้ ซอร์สโค้ดทั้งหมดอยู่ในลิงค์นี้:

https://imanolbarba.net/gitlab/imanol/DiREKT

มันลบสิ่งทั้งหมดหลังจากผ่านไปครู่หนึ่ง แต่มันก็สามารถทำงานได้ฉันหวังว่ามันจะช่วยคนที่ (เหมือนฉัน) ให้ทำงานในประเด็นที่น่าผิดหวังเช่นเดียวกัน

ฉันก็มีสิ่งนี้เช่นกันในระบบ Windows 10 แบบสแตนด์อโลน C: \ User \ ชื่อ \ Repeat \ Repeat \ Repeat \ Repeat \ Repeat \ Repeat \ Repeat \ Repeat ดูเหมือนจะไม่มีที่สิ้นสุด

ฉันสามารถนำทางโดยใช้ Windows หรือ Command Prompt เพื่อประมาณวันที่ 50 และอีกต่อไป ฉันไม่สามารถลบมันหรือคลิกที่มัน ฯลฯ

C คือภาษาของฉันดังนั้นในที่สุดฉันก็เลยเขียนโปรแกรมด้วยการวนรอบการเรียกของระบบซึ่งทำซ้ำจนกว่าพวกเขาจะล้มเหลว คุณสามารถทำสิ่งนี้ได้ในทุกภาษาแม้ว่าจะเป็นชุด DOS ฉันสร้างไดเร็กตอรี่ชื่อว่า tmp และย้าย Repeat \ Repeat ไปแล้ว, ลบโฟลเดอร์ Repeat ที่ว่างแล้ว, และย้าย tmp \ Repeat กลับไปยังโฟลเดอร์ปัจจุบัน. ครั้งแล้วครั้งเล่า!

 while (times<2000)
 {
  ChkSystem("move Repeat\\Repeat tmp");
  ChkSystem("rd Repeat");
  ChkSystem("move tmp\\Repeat Repeat");
  ++times;
  printf("Removed %d nested so far.\n", times);
 }

ChkSystem เพียงเรียกใช้การเรียกใช้ระบบ () และตรวจสอบค่าส่งคืนหยุดถ้ามันล้มเหลว

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