Xóa một thư mục đệ quy vô hạn (dường như)

Bằng cách nào đó, một trong các hộp Server 2008 cũ (không phải R2) của chúng tôi đã phát triển một thư mục dường như vô hạn đệ quy. Đây là chơi havock với các bản sao lưu của chúng tôi, vì tác nhân sao lưu cố gắng lặp lại vào thư mục và không bao giờ quay trở lại.

Cấu trúc thư mục trông giống như:

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

... và cứ thế. Nó giống như một trong những bộ Mandelbrot mà chúng ta từng chơi cùng trong những năm 90.

Tôi đã thử:

• Xóa nó khỏi Explorer. Vâng, tôi là một người lạc quan.
• RMDIR C:\Storage\Folder1 /Q/S - cái này trả về The directory is not empty
• ROBOCOPY C:\temp\EmptyDirectory C:\Storage\Folder1 /PURGE - điều này sẽ quay qua các thư mục trong vài phút trước khi gặp sự cố robocopy.exe.

Bất cứ ai có thể đề nghị một cách để giết thư mục này cho tốt?

Cảm ơn mọi người vì những lời khuyên hữu ích.

Đi lạc vào lãnh thổ StackOverflow, tôi đã giải quyết vấn đề bằng cách gõ đoạn mã C # này. Nó sử dụng thư viện Delimon.Win32.IO đặc biệt giải quyết các vấn đề khi truy cập các đường dẫn tệp dài.

Chỉ trong trường hợp điều này có thể giúp người khác thoát ra, đây là mã - nó đã vượt qua ~ 1600 cấp độ đệ quy mà bằng cách nào đó tôi đã bị mắc kẹt và mất khoảng 20 phút để loại bỏ tất cả.

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

Có thể là một điểm giao tiếp đệ quy. Một thứ như vậy có thể được tạo ra với junctionmột tiện ích tệp và đĩa từ Sysiternals .

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

Và bây giờ bạn có thể đi xuống vô tận c: \ Hello \ Hello \ Hello .... (cho đến khi đạt được MAX_PATH, 260 ký tự cho hầu hết các lệnh nhưng 32.767 ký tự cho một số chức năng API của Windows).

Một danh sách thư mục cho thấy rằng đó là một ngã ba:

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

Để xóa sử dụng tiện ích ngã ba:

junction -d c:\Hello\Hello

Không phải là một câu trả lời, nhưng tôi không có đủ đại diện cho một bình luận.

Tôi đã từng khắc phục sự cố này trên đĩa FAT16 500 MB rất lớn trên hệ thống MS-DOS. Tôi đã sử dụng DOS gỡ lỗi để tự đổ và phân tích cú pháp thông qua bảng thư mục. Sau đó tôi lật một bit để đánh dấu thư mục đệ quy là đã xóa. Bản sao của tôi về Dettman và Wyatt 'Tài liệu tham khảo cho các lập trình viên DOS đã chỉ cho tôi cách.

Tôi vẫn vô cùng tự hào về điều này. Tôi sẽ ngạc nhiên và kinh hoàng nếu có bất kỳ công cụ đa năng nào có sức mạnh như vậy đối với các ổ đĩa FAT32 hoặc NTFS. Cuộc sống đã đơn giản hơn khi đó.

Java cũng có thể xử lý các đường dẫn tệp dài. Và nó cũng có thể làm điều đó nhanh hơn rất nhiều. Mã này (mà tôi đã sao chép từ tài liệu API Java) sẽ xóa cấu trúc thư mục sâu 1600 cấp trong khoảng 1 giây (trong Windows 7, Java 8.0) và không có nguy cơ tràn ngăn xếp vì nó không thực sự sử dụng đệ quy.

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

Bạn không cần tên đường dẫn dài nếu bạn chdirvào thư mục và chỉ sử dụng các đường dẫn tương đối rmdir.

Hoặc, nếu bạn đã cài đặt vỏ POSIX hoặc chuyển cổng này sang DOS tương đương:

# 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

(Sử dụng biến shell để theo dõi nơi bạn đổi tên nó cho điều kiện vòng lặp là cách khác để hủy bỏ vòng lặp như tôi đã làm ở đó.)

Điều này tránh được chi phí CPU của giải pháp KenD, điều này buộc HĐH phải vượt qua cây từ cấp cao nhất đến ncấp độ mỗi khi thêm cấp độ mới, kiểm tra quyền, v.v. Vì vậy, nó có sum(1, n) = n * (n-1) / 2 = O(n^2)độ phức tạp về thời gian. Các giải pháp cắt bỏ một đoạn từ đầu chuỗi nên được O(n), trừ khi Windows cần duyệt qua cây khi đổi tên thư mục mẹ của nó. (Linux / Unix không.) Các giải pháp chdirđi xuống tận cùng của cây và sử dụng các đường dẫn tương đối từ đó, xóa các thư mục khi chúng chdirsao lưu, cũng nên O(n), giả sử HĐH không cần kiểm tra tất cả thư mục cha mẹ mỗi cuộc gọi hệ thống, khi bạn làm mọi thứ trong khi CD ở đâu đó.

find Folder1 -depth -execdir rmdir {} +sẽ chạy rmdir trong khi CD vào thư mục sâu nhất. Hoặc thực tế, -deletetùy chọn find hoạt động trên các thư mục và ngụ ý -depth. Vì vậy, find Folder1 -deletenên làm điều tương tự chính xác, nhưng nhanh hơn. Vâng, GNU tìm thấy trên Linux xuống bằng cách quét một thư mục, ghi vào thư mục con với các đường dẫn tương đối, sau đó rmdirvới một đường dẫn tương đối, sau đó chdir(".."). Nó không quét lại các thư mục trong khi tăng dần, vì vậy nó sẽ tiêu thụ O(n)RAM.

Đó là thực sự là một xấp xỉ: stracechương trình nó thực sự sử dụng unlinkat(AT_FDCWD, "tmp", AT_REMOVEDIR), open("..", O_DIRECTORY|...)và fchdir(the fd from opening the directory), với một loạt các fstatcuộc gọi trộn lẫn trong, quá. Nhưng hiệu ứng là như nhau nếu cây thư mục không được sửa đổi trong khi find đang chạy.

chỉnh sửa: Chỉ để thực hiện, tôi đã thử điều này trên GNU / Linux (Ubuntu 14.10, trên CPU Core2Duo thế hệ đầu tiên 2,4 GHz, trên hệ thống tệp XFS trên ổ đĩa Green Power WD WD (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 tạo một thư mục và bất kỳ thành phần đường dẫn bị thiếu nào).

Vâng, thực sự 0,05 giây cho 2k rmdir ops. xfs khá giỏi trong việc kết hợp các hoạt động siêu dữ liệu với nhau trên tạp chí, vì chúng đã sửa lỗi các dữ liệu meta bị chậm như 10 năm trước.

Trên ext4, tạo mất 0m0.279s, xóa với find vẫn mất 0m0.074s.

Tôi đã gặp vấn đề tương tự với một mớ thư mục sâu hơn 5000 thư mục mà một số ứng dụng Java đã làm và tôi đã viết một chương trình sẽ giúp bạn xóa thư mục này. Toàn bộ mã nguồn nằm trong liên kết này:

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

Nó đã loại bỏ toàn bộ sau một thời gian, nhưng nó đã xoay sở để thực hiện công việc, tôi hy vọng nó sẽ giúp những người (như tôi), gặp phải vấn đề bực bội tương tự

Tôi cũng đã có điều này, trên một hệ thống Windows 10 độc lập. C: \ Người dùng \ Tên \ Lặp lại \ Lặp lại \ Lặp lại \ Lặp lại \ Lặp lại \ Lặp lại \ Lặp lại dường như vô cùng.

Tôi có thể điều hướng bằng Windows hoặc Command Prompt đến khoảng thứ 50 và không cần thêm nữa. Tôi không thể xóa nó, hoặc bấm vào nó, v.v.

C là ngôn ngữ của tôi nên cuối cùng tôi đã viết một chương trình với một vòng lặp các cuộc gọi hệ thống, lặp lại cho đến khi chúng thất bại. Bạn có thể làm điều này bằng bất kỳ ngôn ngữ nào, ngay cả lô DOS. Tôi đã tạo một thư mục có tên là tmp và di chuyển Lặp lại \ Lặp lại vào đó, xóa thư mục Lặp lại trống rỗng và di chuyển tmp \ Lặp lại vào thư mục hiện tại. Lặp đi lặp lại!

 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 chỉ chạy một lệnh hệ thống () và kiểm tra giá trị trả về, dừng lại nếu thất bại.

Điều quan trọng, nó đã thất bại một số lần. Tôi nghĩ có lẽ chương trình của tôi không hoạt động, hoặc nó dài vô tận. Tuy nhiên, tôi đã có điều này trước đây với các cuộc gọi hệ thống, với những thứ không được đồng bộ hóa, vì vậy tôi chỉ chạy chương trình một lần nữa và nó tiếp tục từ nơi nó dừng lại, vì vậy đừng nghĩ rằng chương trình của bạn không hoạt động. Vì vậy, tổng cộng, sau khi chạy nó khoảng 20 lần, nó đã xóa tất cả. Tổng cộng, ban đầu nó có khoảng 1280 thư mục. Không biết điều gì gây ra nó. Khùng.