(जाहिरा तौर पर) असीम रूप से पुनरावर्ती फ़ोल्डर को हटाना

Question

किसी तरह, हमारे पुराने सर्वर 2008 (आर 2 नहीं) के एक बॉक्स ने एक प्रतीत होता है कि असीम रूप से पीछे हटने वाला फ़ोल्डर विकसित किया है। यह हमारे बैकअप के साथ खेल रहा है, क्योंकि बैकअप एजेंट फ़ोल्डर में वापस आने की कोशिश करता है और कभी नहीं लौटता है।

फ़ोल्डर संरचना कुछ इस तरह दिखती है:

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

... और इसी तरह। यह उन मैंडलब्रॉट सेटों में से एक है जैसे हम 90 के दशक में सभी के साथ खेलते थे।

मैंने कोशिश की:

• इसे एक्सप्लोरर से हटा रहा है। हाँ, मैं एक आशावादी हूँ।
• RMDIR C:\Storage\Folder1 /Q/S - यह रिटर्न The directory is not empty
• ROBOCOPY C:\temp\EmptyDirectory C:\Storage\Folder1 /PURGE - यह Robocopy.exe क्रैश होने से पहले कुछ मिनट के लिए फ़ोल्डर्स के माध्यम से घूमता है।

किसी को भी अच्छा करने के लिए इस फ़ोल्डर को मारने का एक तरीका सुझा सकते हैं?

Comments

मैं /MIRइसके बजाय कोशिश करूँगा : ROBOCOPY /MIR C:\temp\EmptyDirectory C:\Storage\Folder1यह भी chkdskसिर्फ गिगल्स के लिए चलने लायक हो सकता है ।

— jscott

/MIRलंबे समय तक लग रहा था, लेकिन अंततः बमबारी भी हुई ("रोबोकॉपी ने काम करना बंद कर दिया")। मैं एक करने के लिए थोड़ा डर रहा हूँ chkdsk; यह एक बहुत पुराना सर्वर है और मुझे चिंता है कि यह समस्या बड़ी फ़ाइल सिस्टम समस्याओं का संकेत है ...

— KenD

एक लिनक्स (उबंटू / सेंटोस / फेडोरा / ...) डेस्कटॉप ट्रायल सीडी से बूट करने की कोशिश करें और फ़ोल्डर को वहां से हटा दें।

— गुंटराम ब्लोहम

@KenD यदि आपको फ़ाइल सिस्टम भ्रष्टाचार के मुद्दों पर संदेह है, तो आपको निश्चित रूप से पहले फ़ाइल सिस्टम की मरम्मत का प्रयास करना चाहिए। निर्देशिका हटाने की कोशिश करने से चालें खराब हो सकती हैं।

— jscott

चूंकि (आपके उत्तर के नीचे से), निर्देशिका अनंत नहीं थी, बस बहुत गहरी थी, अगर आपके पास CygWin या UnxUtils स्थापित था, तो आप findपहले निर्देशिका को हटाने के लिए गहराई का उपयोग कर सकते थे :find Storage/Folder1 -depth -exec rmdir {} \;

— जॉनी

Answer 1

उपयोगी सलाह के लिए सभी को धन्यवाद।

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

Comments

मैंने कोशिश की, यहां तक ​​कि .Delete(सामान्य System.IOसंस्करण के बजाय ) के डेलिमोन संस्करण का उपयोग करते हुए , और हालांकि यह एक अपवाद नहीं फेंकता था, यह कुछ भी करने के लिए नहीं लगता था। निश्चित रूप से उपरोक्त विधि का उपयोग करने वाली पुनरावृत्ति ने उम्र ली, और .Deleteकेवल 5-10 सेकंड के लिए चीजों को चबाया। शायद यह कुछ निर्देशिकाओं में दूर चला गया और फिर छोड़ दिया?

— KenD

क्या आपने कभी यह पता लगाया कि इसके साथ शुरुआत कैसे हुई? कुछ वास्तव में बुरी तरह से लिखा उपयोगकर्ता कार्यक्रम की गलती की तरह लगता है।

— पार्थियन शॉट

1600 बार किसी फंक्शन में रिकवेस्ट करना? ढेर अतिप्रवाह क्षेत्र वास्तव में!

— एलेक्ट्रा डबलिनस्की

एक तरफ के रूप में, फ़ोल्डर्स कुछ भी आबादी थे? यदि आप यह निर्धारित कर सकते हैं कि पुनरावर्ती फ़ोल्डर किस अंतराल पर बनाए गए थे और पुनरावृत्ति की संख्या से गुणा करें, तो आपको (उम्मीद है) इस समस्या के शुरू होने पर एक कठिन समय सीमा प्राप्त होगी ...

— Get-HomeByFiveOClock

वाह, खुशी है कि आपने इसे हल कर दिया। FYI करें, आधिकारिक Microsoft ने इस तरह की स्थिति के लिए फिक्स का समर्थन किया है "वॉल्यूम में सुधार।" हाँ, गंभीरता से। : /

— हॉपलेसएनबीबी

Answer 2

एक पुनरावर्ती जंक्शन बिंदु हो सकता है। Sysinternalsjunction से एक फ़ाइल और डिस्क उपयोगिता के साथ इस तरह की चीज बनाई जा सकती है ।

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

और अब आप अंतहीन रूप से नीचे जा सकते हैं c: \ Hello \ Hello \ Hello .... (जब तक MAX_PATH तक नहीं पहुंच जाता है, अधिकांश कमांड के लिए 260 वर्ण लेकिन कुछ विंडोज एपीआई कार्यों के लिए 32,767 वर्ण)।

एक निर्देशिका सूची से पता चलता है कि यह एक जंक्शन है:

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 -d c:\Hello\Hello

Comments

दुर्भाग्य से, एक DIRबस मुझे सादा ओले निर्देशिकाओं से पता चलता है - मुझे कोई डर नहीं है, मुझे डर है

— KenD

क्या आप एक त्वरित दोहरी जांच कर सकते हैं junction -s C:\Storage\Folder1 ?

— ब्रायन

No reparse points found:(

— KenD

मुझे आश्चर्य है कि क्या वास्तविक उप निर्देशिकाओं की ऐसी गड़बड़ी पैदा हुई।

— ब्रायन

dir /aविशिष्ट नाम निर्दिष्ट किए बिना '<JUNCTION>' देखने के लिए उपयोग करें ।

— क्लो

Answer 3

उत्तर नहीं, लेकिन मेरे पास एक टिप्पणी के लिए पर्याप्त प्रतिनिधि नहीं है।

मैंने एक बार MS-DOS सिस्टम पर 500MB FAT16 डिस्क पर इस समस्या को ठीक किया। मैंने DOS डिबग का उपयोग मैन्युअल रूप से डंप और पार्स करने के लिए डायरेक्टरी टेबल के माध्यम से किया। मैं फिर से हटाए गए के रूप में पुनरावर्ती निर्देशिका को चिह्नित करने के लिए एक सा फ़्लिप किया। डेटमैन और वायट के 'डॉस प्रोग्रामर्स रेफरेंस' की मेरी कॉपी ने मुझे रास्ता दिखाया।

मुझे आज भी इस पर गर्व है। अगर कोई सामान्य प्रयोजन उपकरण है जो FAT32 या NTFS वॉल्यूम पर ऐसी शक्ति है, तो मैं चकित और आतंकित रहूंगा। जीवन तब सरल था।

Comments

मैं कहूँगा कि आप कर रहे हैं उचित इस पर गर्व।

— मफिनी

+1 का मेरे ऊपर कुछ प्रतिनिधि है। अच्छा समाधान है।

— क्रिस थॉर्नटन

अब आप अपने उत्तर के पहले वाक्य को हटा सकते हैं।

— AL

यह कोई उत्तर नहीं है। यह एक अलग ऑपरेटिंग सिस्टम और एक अलग फाइल सिस्टम के बारे में एक कहानी है। इस (NT, NTFS) समस्या के लिए कोई मदद नहीं होने के अलावा, यह किसी को भी एक ही समस्या (DOS, FAT16) से मदद नहीं करेगा क्योंकि इसमें वास्तव में कोई विवरण नहीं है।

— एंड्रयू मेडिको

@ और मेडिको: मैं आपसे सहमत हूं, इसलिए मेरा पहला वाक्य है। लेकिन मैं आपको बताता हूं कि कहां से संबंधित समस्या को हल करने के लिए जानकारी ढूंढनी है।

— रिचर्ड

Answer 4

जावा लंबी फ़ाइल पथों से भी निपट सकता है। और यह इसे बहुत तेजी से भी कर सकता है। यह कोड (जिसे मैंने जावा एपीआई डॉक्यूमेंट से कॉपी किया था) लगभग 1600 सेकंड (विंडोज 7, जावा 8.0 के तहत) में 1600 के स्तर की गहरी निर्देशिका संरचना को हटा देगा और स्टैक ओवरफ्लो का कोई खतरा नहीं है क्योंकि यह वास्तव में पुनरावृत्ति का उपयोग नहीं करता है।

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

Comments

मैं तुमसे नफ़रत करता हूं। आपने मुझे एक उत्तर देने के लिए मजबूर किया है जिसमें जावा का उपयोग करना शामिल है, और अब मुझे सब गंदा लगता है। मुझे फुहारे में स्नान करने की आवश्यकता है।

— होपलेस

मैं क्षमाप्रार्थी हूं। मुझे आशा है कि आप अपने आघात से अंततः ठीक हो जाएंगे। लेकिन क्या Microsoft द्वारा विकसित भाषा (c #) वास्तव में बहुत बेहतर है?

— स्पाइडरपिग

मैं इन दिनों मुख्य रूप से एक विंडोज लड़का हूं, इसलिए हां, हां यह है। मैं जावा के खिलाफ कड़वा और पक्षपाती हो सकता हूं, मेरे नियोक्ता के वातावरण में लगभग 1,000 ग्राहकों में जेआरई के 5 विशिष्ट, अलग-अलग संस्करणों को बनाए रखने के कारण, जिनमें से एक 2009 से 2009 तक, क्रैप ... एर, मैलवेयर के खाते में है। ... उह, "एंटरप्राइज-वाई" सॉफ्टवेयर सूट करता है जो हम व्यापार महत्वपूर्ण अनुप्रयोगों के लिए उपयोग करते हैं।

— होपलेस

Answer 5

यदि आपको chdirनिर्देशिका में है तो आपको लंबे पथनामों की आवश्यकता नहीं है और बस सापेक्ष पथों का उपयोग करें rmdir।

या, यदि आपके पास एक 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

(लूप स्थिति के लिए इसका नाम बदलकर ट्रैक करने के लिए शेल चर का उपयोग करना, लूप को अनियंत्रित करने का दूसरा विकल्प है जैसे मैंने वहां किया था।)

यह केनडी के समाधान के सीपीयू ओवरहेड से बचा जाता है, जो ओएस को पेड़ से ऊपर से nवें स्तर तक हर बार एक नया स्तर जोड़ने, अनुमतियों की जांच आदि के लिए मजबूर करता है, इसलिए इसमें sum(1, n) = n * (n-1) / 2 = O(n^2)समय की जटिलता होती है। समाधान जो श्रृंखला की शुरुआत से एक पंक को बंद करते हैं O(n), जब तक कि विंडोज को अपने मूल निर्देशिका का नाम बदलने के दौरान एक पेड़ को पार करने की आवश्यकता न हो । (लिनक्स / यूनिक्स नहीं है।) समाधान जो chdirपेड़ के नीचे तक सभी तरह से आते हैं और वहां से रिश्तेदार रास्तों का उपयोग करते हैं, निर्देशिकाओं को हटाते हुए जैसे वे chdirवापस आते हैं, वैसे ही O(n), यह मानते हुए कि ओएस को आपके सभी की जांच करने की आवश्यकता नहीं है पैरेंट डाइरेक्टरी हर सिस्टम कॉल, जब आप काम करते हैं तो कहीं न कहीं सीडेड।

find Folder1 -depth -execdir rmdir {} +rmdir चलाएंगे, जबकि सबसे गहरी निर्देशिका में सीडी। या वास्तव में, खोज का -deleteविकल्प निर्देशिकाओं पर काम करता है, और इसका मतलब है -depth। तो find Folder1 -deleteठीक वही काम करना चाहिए, लेकिन तेजी से। हाँ, जीएनयू लिनक्स पर एक निर्देशिका को स्कैन करके, सापेक्ष पथों के साथ उपनिर्देशिकाओं के लिए, फिर rmdirएक सापेक्ष पथ के साथ , फिर उतरता है chdir("..")। यह आरोही करते समय निर्देशिकाओं का पुनरुत्थान नहीं करता है, इसलिए यह O(n)रैम का उपभोग करेगा ।

: यह वास्तव में एक सन्निकटन था straceपता चलता है कि यह वास्तव में उपयोग करता है unlinkat(AT_FDCWD, "tmp", AT_REMOVEDIR), open("..", O_DIRECTORY|...)और fchdir(the fd from opening the directory), के एक समूह के साथ fstatभी में मिलाया कॉल। लेकिन प्रभाव एक ही है अगर निर्देशिका ट्री संशोधित नहीं हो रहा है जबकि खोज चल रही है।

संपादित करें: सिर्फ kicks के लिए, मैंने GNU / Linux (Ubuntu 14.10, 2.4GHz फर्स्ट-जीन Core2Duo CPU पर, WD 2.5TB ग्रीन पावर ड्राइव (WD25EZRS) पर XFS फाइलसिस्टम पर) यह कोशिश की।

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 एक निर्देशिका और किसी भी लापता पथ घटक बनाता है)।

हाँ, 2k rmdir ops के लिए वास्तव में 0.05 सेकंड। पत्रिका में मेटाडेटा संचालन को एक साथ करने में एक्सएफ़एस काफी अच्छा है, क्योंकि वे मेटा डेटा ऑप्स 10 साल पहले की तरह धीमा थे।

Ext4 पर, बनाएं 0m0.279s, अभी भी लिया गया 0m0.074s के साथ हटाएं।

Comments

जिज्ञासु हो गए और इसे लिनक्स पर आज़माया। मानक GNU उपकरण लंबे रास्तों के साथ सभी ठीक हैं, क्योंकि वे विशाल लंबे रास्तों के साथ सिस्टम कॉल करने की कोशिश करने के बजाय पेड़ को नीचे गिरा देते हैं। यहां तक ​​कि जब आप इसे कमांड लाइन पर 38k पथ से गुजरते हैं तो भी mkdir ठीक है!

— पीटर कॉर्ड्स

Answer 6

मैंने 5000+ डायरेक्टरी-डीप फोल्डर मेस के साथ एक ही इश्यू में रन किया जो कि कुछ जावा एप्लिकेशन ने किया था और मैंने एक प्रोग्राम लिखा था जो आपको इस फोल्डर को हटाने में मदद करेगा। पूरा स्रोत कोड इस लिंक में है:

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

इसने थोड़ी देर के बाद पूरी बात को हटा दिया, लेकिन यह काम करने में कामयाब रहा, मुझे उम्मीद है कि यह उन लोगों की मदद करता है जो (जैसा कि), मैं एक ही निराशाजनक मुद्दे पर चलता हूं

Comments

कृपया लिंक-केवल उत्तर पोस्ट न करें। आपको पोस्ट में लिंक से सबसे महत्वपूर्ण जानकारी स्वयं डालनी चाहिए और संदर्भ के लिए लिंक प्रदान करना चाहिए।

— फ्रेडरिक नीलसन

ओह क्षमा करें, यह एक कार्यक्रम है, और मैं वास्तव में यहां सभी स्रोत कोड पोस्ट नहीं करना चाहता था ... मुझे लगता है कि यह बहुत स्पष्ट है कि मैंने एक कार्यक्रम लिखा है और मैं इस लिंक का पालन कर रहा हूं, और प्रेरणा और सभी में है उत्तर, इसलिए यह मुझे स्पष्ट रूप से एक लिंक-केवल उत्तर नहीं दिखता है, फिर भी, मैं (अधिक स्पष्ट रूप से) निर्दिष्ट करूंगा कि यह इस समस्या को हल करने के लिए चलाया जाने वाला एक सॉफ्टवेयर है

— Imanol Barba Sabariego

Answer 7

मैं भी एक स्वसंपूर्ण विंडोज 10 प्रणाली पर यह था, हालांकि। C: \ User \ Name \ दोहराने \ दोहराने \ दोहराने \ दोहराने \ दोहराने \ दोहराने \ अनंत के लिए प्रतीत होता है।

मैं लगभग 50 वें एक और आगे नहीं विंडोज या कमांड प्रॉम्प्ट का उपयोग करके नेविगेट कर सकता हूं। मैं इसे हटा नहीं सकता था, या उस पर क्लिक नहीं कर सकता था, आदि।

सी मेरी भाषा है इसलिए अंततः मैंने सिस्टम कॉल के लूप के साथ एक कार्यक्रम लिखा, जो तब तक दोहराते हैं जब तक वे विफल नहीं हो जाते। आप इसे किसी भी भाषा में कर सकते हैं, यहां तक ​​कि डॉस बैच भी। मैंने tmp नाम की एक निर्देशिका बनाई और उस में रिपीट \ रिपीट को स्थानांतरित कर दिया, अब-खाली रिपीट फ़ोल्डर को हटा दिया, और वर्तमान फ़ोल्डर में वापस tmp \ दोहराएँ को स्थानांतरित कर दिया। बार बार!

 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 फ़ोल्डर्स गहरा था। पता नहीं इसका क्या कारण था। पागल।