सवाल एक (जाहिर है) असीमित रिकर्सिव फ़ोल्डर को हटा रहा है


किसी भी तरह, हमारे पुराने सर्वर 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 दुर्घटनाओं से पहले कुछ मिनट के लिए फ़ोल्डर्स के माध्यम से यह स्पिन करता है।

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


45
2018-02-12 11:12


मूल


मैं कोशिश करता हूँ /MIR बजाय: ROBOCOPY /MIR C:\temp\EmptyDirectory C:\Storage\Folder1 एक चलाने के लायक भी हो सकता है chkdsk बस गिगल्स के लिए। - jscott
/MIR लग रहा था कि लंबे समय तक चल रहा था, लेकिन अंत में भी बाहर निकला ("रोबोकॉपी ने काम करना बंद कर दिया है")। मैं थोड़ा करने के लिए डर रहा हूँ chkdsk; यह एक सुंदर पुराना सर्वर है और मुझे चिंता है कि यह समस्या बड़ी फाइल सिस्टम समस्याओं का संकेत है ... - KenD
लिनक्स (उबंटू / सेंटोस / फेडोरा / ...) डेस्कटॉप परीक्षण सीडी से बूट करने का प्रयास करें और वहां से फ़ोल्डर को हटा दें। - Guntram Blohm
@ केएनडी अगर आपको फाइल सिस्टम भ्रष्टाचार के मुद्दों पर संदेह है, तो आपको निश्चित रूप से पहले फाइल सिस्टम की मरम्मत करने की कोशिश करनी चाहिए। निर्देशिका हटाने की कोशिश करने से चीजों को और भी खराब हो सकता है। - jscott
चूंकि (नीचे दिए गए आपके उत्तर से), निर्देशिका अनंत नहीं थी, बस आपके पास बहुत गहरी थी Cygwin या UnxUtils स्थापित, आप उपयोग कर सकते हैं find गहराई करने के लिए पहली निर्देशिका हटाने के लिए: find Storage/Folder1 -depth -exec rmdir {} \; - Johnny


जवाब:


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

StackOverflow क्षेत्र में अच्छी तरह से भटकना, मैंने सी # कोड के इस स्निपेट को खटखटाकर समस्या हल कर दी है। यह उपयोग करता है 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--;
        }
    }
}

45
2018-02-12 18:44



मैंने कोशिश की, यहां तक ​​कि डेलीमॉन संस्करण का उपयोग भी किया .Delete (सामान्य की बजाय System.IO संस्करण), और हालांकि यह एक अपवाद नहीं फेंक दिया यह कुछ भी प्रतीत नहीं होता था। निश्चित रूप से ऊपर की विधि का उपयोग कर रिकर्सन उम्र ले लिया, और .Delete केवल 5-10 सेकंड के लिए चीजों पर चबाया। शायद यह कुछ निर्देशिकाओं में चले गए और फिर छोड़ दिया? - KenD
क्या आपने कभी यह पता लगाया कि यह कैसे शुरू हुआ? कुछ वास्तव में बुरी तरह लिखित उपयोगकर्तालैंड कार्यक्रम की गलती की तरह लगता है। - Parthian Shot
1600 बार एक समारोह में recursing? स्टैक ओवरफ़्लो वास्तव में क्षेत्र! - Aleksandr Dubinsky
एक तरफ के रूप में, फ़ोल्डर्स कुछ भी आबादी थे? यदि आप निर्धारित कर सकते हैं कि रिकर्सिव फ़ोल्डर्स किस अंतराल को बनाए गए थे और रिकर्सन की संख्या से गुणा करते हैं, तो आप इस समस्या को शुरू करने के दौरान (उम्मीद है) एक मोटा समय सीमा प्राप्त करेंगे ... - Get-HomeByFiveOClock
वाह, खुशी है कि आप इसे हल करने के लिए समाप्त हो गया। एफवाईआई, इस तरह की स्थिति के लिए आधिकारिक माइक्रोसॉफ्ट समर्थित फिक्स "वॉल्यूम को दोबारा सुधारना" है। हाँ, गंभीरता से। : / - HopelessN00b


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

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

25
2018-02-12 13:28



दुर्भाग्य से, ए DIR बस मुझे सादे ओले निर्देशिका दिखाता है - मुझे डरने वाले किसी भी जंक्शन का कोई संकेत नहीं है - KenD
क्या आप एक त्वरित डबल चेक कर सकते हैं junction -s C:\Storage\Folder1  ? - Brian
No reparse points found :( - KenD
मुझे आश्चर्य है कि वास्तविक उप निर्देशिकाओं की इतनी गड़बड़ी किसने बनाई है। - Brian
उपयोग dir /a विशिष्ट नाम निर्दिष्ट किए बिना '<JUNCTION>' देखने के लिए। - Chloe


कोई जवाब नहीं है, लेकिन मेरे पास टिप्पणी के लिए पर्याप्त प्रतिनिधि नहीं है।

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

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


16
2018-02-13 14:06



मैं कहूंगा कि तुम हो उचित इस पर गर्व है। - mfinni
+1 पर कुछ प्रतिनिधि हैं। अच्छा समाधान - Chris Thornton
अब आप अपने उत्तर की पहली वाक्य हटा सकते हैं। - A.L
यह एक जवाब नहीं है। यह एक अलग ऑपरेटिंग सिस्टम और एक अलग फाइल सिस्टम के बारे में एक कहानी है। इस (एनटी, एनटीएफएस) की समस्या के लिए कोई मदद नहीं होने के अलावा, यह किसी भी समस्या (डीओएस, एफएटी 16) के साथ किसी की भी मदद नहीं करेगा क्योंकि इसमें वास्तव में कोई विवरण नहीं है। - Andrew Medico
@ एंड्रयू मेडिको: मैं आपसे सहमत हूं, इसलिए मेरी पहली वाक्य। लेकिन मैं आपको बताता हूं कि थोड़ी-थोड़ी समस्या को हल करने के लिए जानकारी कहां प्राप्त करें। - Richard


जावा लंबे फ़ाइल पथ से भी निपट सकता है। और यह भी बहुत तेज़ कर सकता है। यह कोड (जिसे मैंने जावा एपीआई दस्तावेज से कॉपी किया है) लगभग 16 सेकंड की गहरी निर्देशिका संरचना को लगभग 1 सेकंड (विंडोज 7, जावा 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"));
  }
}

8
2018-02-14 17:35



मैं तुमसे नफ़रत करता हूं। आपने मुझे जावा का उपयोग करने वाले एक उत्तर को ऊपर उठाने के लिए मजबूर कर दिया है, और अब मैं सभी गंदे महसूस करता हूं। मुझे फुहारे में स्नान करने की आवश्यकता है। - HopelessN00b
मैं क्षमाप्रार्थी हूं। मुझे उम्मीद है कि आप अंततः अपने आघात से ठीक हो जाएंगे। लेकिन माइक्रोसॉफ्ट (सी #) द्वारा विकसित एक भाषा वास्तव में बहुत बेहतर है? - SpiderPig
मैं मुख्य रूप से इन दिनों एक विंडोज लड़का हूँ, तो हाँ, हाँ यह है। मैं अपने नियोक्ता के पर्यावरण में लगभग 1000 ग्राहकों में जेआरई के 5 विशिष्ट, विभिन्न संस्करणों को बनाए रखने के कारण जावा के खिलाफ कड़वा और पक्षपाती भी हो सकता हूं, जिनमें से एक 200 9 की तारीख है, बकवास के कारण ... er, मैलवेयर ... ओह, "एंटरप्राइज-वाई" सॉफ्टवेयर सूट जो हम व्यापार महत्वपूर्ण अनुप्रयोगों के लिए उपयोग करते हैं। - HopelessN00b


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

या, यदि आपके पास एक POSIX खोल स्थापित है, या इसे डॉस समकक्ष पर पोर्ट करें:

# 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 {} + गहरी निर्देशिका में सीडी होने पर आरएमडीआईआर चलाएगा। या वास्तव में, पाते हैं -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 कॉल भी मिश्रित है। लेकिन प्रभाव तब भी वही है जब निर्देशिका पेड़ चल रहा है जबकि संशोधित नहीं हो रहा है।

संपादित करें: बस किक्स के लिए, मैंने इसे डब्लूडी 2.5 टीबी ग्रीन पावर ड्राइव (डब्ल्यूडी 25 ईजेआरएस) पर एक एक्सएफएस फाइल सिस्टम पर 2.4 गीगाहर्ट्ज फर्स्ट-जेन कोर 2 डीयूओ सीपीयू पर जीएनयू / लिनक्स (उबंटू 14.10) पर कोशिश की।

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 ढूंढने के साथ हटाएं।


6
2018-02-15 05:40



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


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

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

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


0
2017-08-08 18:35



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


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

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

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


0
2018-03-31 16:24





लोकप्रिय प्रश्न

विंडोज सर्वर 2012 अनुसूचित कार्य डिफ़ॉल्ट प्रोफ़ाइल का उपयोग करते हुए चलाते हैं (जब सत्र कम हो जाता है) भले ही विशिष्ट खाता निर्दिष्ट हो एक साझा आईपी पते पर एकाधिक डोमेन के लिए पीटीआर रिकॉर्ड (आरडीएनएस) सक्रिय निर्देशिका का उपयोग कर गैर-माइक्रोसॉफ्ट अनुप्रयोगों के अद्यतन स्थापित करने के लिए गैर-व्यवस्थापक खातों को कॉन्फ़िगर कैसे करें? वेब नियंत्रण कक्ष के माध्यम से मैं रूट को सुरक्षित रूप से रूट के रूप में कैसे निष्पादित कर सकता हूं? डेस्कटॉप के लिए फाइबर - जो कनेक्टर मैं यूएसबी कीबोर्ड का उपयोग करने के लिए एनाकोंडा के एससीएपी ऐड-ऑन को कैसे बल दूं? कैसे बताएं कि कौन सी स्थानीय शाखा गिट में रिमोट शाखा को ट्रैक कर रही है?