उपयोगकर्ता RECYCLER फ़ोल्डर में हजारों छिपी हुई फाइलें हैं

Question

हमारे पास एक "उपयोगकर्ता" फ़ोल्डर है जो सभी उपयोगकर्ता फ़ाइलों और नेटवर्क प्रोफाइल की जड़ है।

एक निर्देशिका आकार उपयोगिता (WinDirStat) का उपयोग करते हुए, मैं एक अजीब और चिंताजनक समस्या पर ठोकर खाई - हजारों फ़ाइलें प्रभावी रूप से विंडोज रीसायकल बिन इंटरफ़ेस में छिपी हुई हैं। प्रत्येक उपयोगकर्ता के फ़ोल्डर में सीधे एक RECYCLER फ़ोल्डर होता है My Documents, जैसे:

\\server1\Users\smithj\smithj's Documents\RECYCLER\S-1-5-21-nnnnnn

हमारे उपयोगकर्ताओं में से कुछ के पास पीसी है, क्योंकि अधिकांश उपयोगकर्ता एक सिम्प्लिक एप्लिकेशन सर्वर पर एक साधारण वायस टर्मिनल से लॉगिन करते हैं। क्योंकि उनकी अधिकांश फ़ाइल गतिविधि नेटवर्क शेयरों पर है, उपयोगकर्ताओं (और हम मानते हैं) ने हमेशा समझा है कि कोई "नेटवर्क रीसायकल बिन" नहीं है।

हालांकि, अधिकांश उपयोगकर्ताओं के लिए छिपे हुए RECYCLER फ़ोल्डर में हजारों फाइलें हैं। कई चीजें बाहर खड़ी हैं:

1. ज्यादातर मामलों में, रीसायकल बिन इंटरफ़ेस का उपयोग करके कोई भी फाइल दिखाई नहीं देती है
2. नामकरण परंपरा अलग-अलग फ़ाइलों के लिए इस तरह के रूप में एक ड्राइव अक्षर शामिल होना चाहिए DCया DD, लेकिन इसके बजाय वे सब के साथ शुरू D@उदाहरण के लिए, - [e-mail]।
3. मेरा मानना ​​है कि @प्रतीक विंडोज को मूल फ़ाइलों को डीफ़्रॉन्फ्रेंस करने से रोक रहा है , इसलिए वे केवल उपयोगकर्ता इंटरफ़ेस में दबाए जाते हैं।
4. फाइलें एक साथ दसियों गीगाबाइट का उपभोग करती हैं। वे भूत नहीं हैं। कुछ फ़ाइलों को हटाने से ड्राइव पर खाली जगह बढ़ जाती है।
5. ऐसा लगता है कि हम वास्तव में एक "नेटवर्क रीसायकल बिन है।" गलती से। असली फ़ाइल नामों के बिना।

हमने पहले ही तय कर लिया है कि हम Xदिनों से पुरानी सभी फ़ाइलों को हटा देंगे । मैं एक PowerShell स्क्रिप्ट के साथ ऐसा कर सकता हूं। इसी तरह के मामले के विपरीत , हम संपूर्ण फ़ोल्डर के बजाय व्यक्तिगत फ़ाइलों को हटाने जा रहे हैं।

तो, मेरे सवाल:

• क्या किसी ने इन @प्रतीकों को रीसायकल बिन फाइलों में देखा है ?
• सभी नेटवर्क ड्राइव का उपयोग मैप किए गए ड्राइव के माध्यम से होता है। क्या यह समझा सकता है कि फ़ाइलों को पुनर्नवीनीकरण क्यों किया जाता है? और छिपा हुआ है?
• यद्यपि हम दैनिक बैकअप चलाते हैं, मैं केवल अंतिम रिसोर्ट फ़ाइल पुनर्प्राप्ति के लिए इस संसाधन को टैप करना चाहता हूं। कोई सुझाव या चेतावनी?

Comments

सुनिश्चित नहीं हैं कि आप अभी भी आस-पास हैं, इस प्रश्न को देखते हुए, लेकिन क्या आप मेरे दस्तावेज़ों को नेटवर्क पथ पर पुनर्निर्देशित कर रहे हैं?

— पैट्रिक सेमुर

इन दो लेखों में मैप्ड नेटवर्क ड्राइव पर नेटवर्क रीसायकल बिन बनाने के निर्देश हैं। आप देख सकते हैं कि उनमें से कोई भी आपके मामले पर लागू होता है: लेख 1 और लेख 2 ।

— harrymc

Answer 1

आप जो देख रहे हैं वह "मेरे दस्तावेज़" फ़ोल्डरों को पुनर्निर्देशित करने के लिए रीसायकल बिन है।

समस्या मेरे लेख फ़ोल्डर फ़ोल्डर पुनर्निर्देशन / रीसायकल बिन में अच्छी तरह से वर्णित है :

उपयोगकर्ताओं को मेरे दस्तावेज़ फ़ोल्डर को पुनर्निर्देशित करने के लिए फ़ोल्डर पुनर्निर्देशन का उपयोग करते समय, उपयोगकर्ता के मेरे दस्तावेज़ फ़ोल्डर से हटाए गए आइटम को उपयोगकर्ता के मेरे दस्तावेज़ फ़ोल्डर [जो एक सर्वर पर रहता है] में एक रीसायकल बिन में संग्रहीत किया जाता है। दुर्भाग्य से रीसायकल बिन का अधिकतम आकार उस ड्राइव के आकार पर आधारित है जिस पर My Documents फ़ोल्डर को पुनर्निर्देशित किया गया है। डिफ़ॉल्ट आकार 10% है। नीति निर्माता रजिस्ट्री क्लाइंट और समूह नीति का उपयोग करते हुए मैंने अपने दस्तावेज़ फ़ोल्डर के लिए रीसायकल बिन का अधिकतम आकार बनाने के लिए आवश्यक सेटिंग्स को धक्का दिया है I%।

समस्या यह है कि 1% अभी भी बड़े पैमाने पर है। मेरे दस्तावेज़ों को पुनर्निर्देशित करने के लिए उपयोग की जा रही ड्राइव वर्तमान में 500GB है। इसमें से 1% 5GB है, जो कि लगभग 2000 उपयोगकर्ताओं के साथ है और यह स्पष्ट है कि इन वर्षों में हम संभावित रूप से बहुत सारी अनावश्यक फ़ाइलों को संग्रहीत कर सकते हैं। 2000 उपयोगकर्ताओं को नियमित रूप से अपने दस्तावेज़ों को शुद्ध करने के लिए शिक्षण या निर्देश देना संभव नहीं है।

लेख फ़ोल्डर पुनर्निर्देशन और रीसायकल बिन यह कहता है:

यदि आप "मेरे दस्तावेज़" को पुनर्निर्देशित करते हैं, तो रीसायकल बिन एक मुद्दा बन सकता है (महंगे सर्वर डिस्क स्थान को बर्बाद करना)।

आप इस रजिस्ट्री कुंजी के साथ रीसायकल बिन व्यवहार को नियंत्रित कर सकते हैं: HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket, NukeOnDelete=1पुनर्निर्देशित फ़ोल्डर के लिए रीसायकल बिन के उपयोग को निष्क्रिय होगा।

एक अन्य आइटम है जिसे कहा जाता UseGlobalSettingsहै 1 यदि इन मापदंडों का उपयोग सभी डिस्क के लिए किया जाता है। मान के साथ 0, प्रत्येक डिस्क के लिए रीसायकल बिन मापदंडों को डिस्क के ड्राइव-अक्षर वाले उप-कुंजी के रूप में पाया जाता है।

हालांकि उस लेख में एक और समस्या सामने आई है:

यह NukeOnDelete कुंजी वास्तव में अच्छी है। हालाँकि, मैं एक और पहेली लाता हूँ ... मेरे दस्तावेज़ों को पुनर्निर्देशित करने के बाद, उपयोगकर्ता के पास दो रीसायकल डिब्बे होंगे - एक स्थानीय फ़ाइलों के लिए, दूसरा पुनर्निर्देशित फ़ाइलों के लिए। जब उपयोगकर्ता रीसायकल बिन को ब्राउज़ करता है तो यह स्वचालित रूप से पुनर्निर्देशित मेरे दस्तावेज़ों को लोड करता है, लेकिन मुझे यह पता नहीं चल सकता है कि स्थानीय रीसायकल बिन तक कैसे पहुंचा जाए। मैं समझता हूं कि स्थानीय रीसायकल बिन C: \ Recycler है, लेकिन यह निर्देशिका हमेशा खाली दिखाई देती है। मुझे पता है कि आदर्श वातावरण में, उपयोगकर्ताओं को स्थानीय सिस्टम से फ़ाइलों को हटाने के लिए पहुंच नहीं होनी चाहिए। मेरे दस्तावेज़ पुनर्निर्देशित करने (पुनर्निर्देशन को अक्षम करने और लॉग / इन करने के अलावा अन्य) के बाद उपयोगकर्ता को स्थानीय रीसायकल बिन तक पहुँचने की अनुमति देने का एक तरीका होना चाहिए ...

रीसायकल बिन आकार को नियंत्रित करने के बारे में उपरोक्त लेख से अधिक जानकारी:

1. MaxCapacity मूल्य पर स्थित हैHKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\KnownFolder\<GUID>
2. हमारे वातावरण में, हम केवल डेस्कटॉप और दस्तावेज़ फ़ोल्डर को सर्वर पर पुनर्निर्देशित करते हैं। इनके लिए GUID हैं (अन्य http://msdn.microsoft.com/en-us/library/bb882665.aspx पर स्थित हैं ):
   1. डेस्कटॉप: B4BFCC3A-DB2C-424C-B029-7FE99A87C641
   2. दस्तावेज़: FDD39AD0-238F-46AF-ADB4-6C85480369C7
3. एक उदाहरण के रूप में, पुनर्निर्देशित डेस्कटॉप फ़ोल्डर को केवल 200mb तक उपयोग करने के लिए सेट करने के लिए, निम्न रजिस्ट्री मान लागू करें:
   HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\BitBucket\KnownFolder\{B4BFCC3A-DB2C-424C-B029-7FE99A87C641}\MaxCapacity=0xC8 (0xC8 हेक्स में 200 है)
4. मैंने इन परिवर्तनों को हमारे पर्यावरण के लिए धकेलने के लिए समूह नीति वरीयताओं का उपयोग किया।
5. मेरे परीक्षण में, इसने रीसायकल बिन में आइटमों को तुरंत शुद्ध नहीं किया जो बड़े थे। हालाँकि, जब मैंने इस रजिस्ट्री सेटिंग को लागू करने के बाद एक नया आइटम हटा दिया था, तो पुराने आइटमों को तुरंत रीसायकल बिन से हटा दिया गया था।

इन फ़ाइलों को हटाने के लिए: ऐसा करने से उपयोगकर्ता के रीसायकल बिन से हटाए गए दस्तावेज़ मिट जाएंगे, इसलिए यह बहुत बड़ी समस्या नहीं हो सकती है। सिवाय इसके कि यह बिन सेटिंग्स को रीसायकल कर सकता है जो उन फ़ाइलों को निर्दिष्ट करता है जो अब मौजूद नहीं हैं। इन सभी फ़ाइलों को हटाने के तुरंत बाद सामान्य रीसायकल बिन को खाली करना बेहतर हो सकता है।

स्पष्ट रूप से, मेरे दस्तावेजों को पुनर्निर्देशित किया गया लगता है कि Microsoft द्वारा रॉयस गड़बड़ किया गया है। आपको गोचरों के बीच नाजुक ढंग से कदम रखना होगा।

Comments

एक अच्छा लेख, लेकिन ध्यान दें कि रीसायकल बिन में छिपी हुई फ़ाइलों की समस्या अभी भी मौजूद है और भले ही आप रीसायकल बिन के लिए अधिकतम आकार सेटिंग को अक्षम कर दें।

— होपलेसनब

Answer 2

WTF? क्या किसी ने इन @ प्रतीकों को रीसायकल बिन फाइलों में देखा है?

हाँ, मैंने इसे विंडोज वातावरण पर देखा है जहाँ तक मुझे याद है। दोनों घर में, एकल उपयोगकर्ता वातावरण और विंडोज क्लाइंट OSes में, और कई उपयोगकर्ताओं के साथ विंडोज सर्वर OSes पर बहु-उपयोगकर्ता वातावरण में काम / स्कूल में।

सभी नेटवर्क ड्राइव का उपयोग मैप्ड ड्राइव के माध्यम से होता है। क्या यह समझा सकता है कि फ़ाइलों को पुनर्नवीनीकरण क्यों किया जाता है? और छिपा हुआ है?

नहीं, आप जो देख रहे हैं वह रीसायकल बिन के काम करने का तरीका है ।

---

जब आप किसी फ़ाइल को हटाते हैं, तो पूर्ण पथ और फ़ाइल का नाम एक छुपी हुई फ़ाइल में संग्रहीत होता है जिसे पुनर्नवीनीकरण फ़ोल्डर में Info या Info2 (Windows 98) कहा जाता है। निम्न सिंटैक्स का उपयोग करके हटाए गए फ़ाइल का नाम बदला गया है:

D<original drive letter of file><#>.<original extension> 

---

जैसा कि "समझाने" के लिए यह विंडोज रीसायकल बिन के साथ क्यों होता है, मैंने " श्रग ... भ्रष्टाचार " से अधिक आधिकारिक स्पष्टीकरण कभी नहीं देखा है । लिंक किए गए लेख का सारांश आपको बताता है कि प्रक्रिया का कौन सा हिस्सा गलत है, लेकिन इस प्रक्रिया के बारे में विस्तार से नहीं पता है कि आपको ठीक से समझाने की आवश्यकता है कि वास्तव में क्या टूट रहा है, और कहां। शायद, अगर उनके पास होता, तो कोई इस मुद्दे को अब तक ठीक कर लेता।

यद्यपि हम दैनिक बैकअप चलाते हैं, मैं अंतिम रिसोर्ट फ़ाइल पुनर्प्राप्ति के लिए इस संसाधन को टैप करने की योजना बना रहा हूं। कोई सुझाव या चेतावनी?

नहीं, दूर हटो। फ़ाइलों को उनके मूल नामों पर पुनर्स्थापित नहीं किया जा सकता है (जैसा कि वे पुनरावृत्ति बिन सामग्री के उस INFO फ़ाइल प्रकट में नहीं हैं), और उपयोगकर्ता उन्हें नहीं देख सकते / नहीं जानते कि वे अब वहां नहीं हैं, इसलिए यह सिर्फ जगह बर्बाद है।

Comments

आप जिस लेख को उद्धृत #करते हैं , उसमें फाइलें होती हैं , जबकि पोस्टर में होती है @। साथ ही, विंडोज 98 के बाद से कई चीजें बदल गई हैं, इसलिए लेख वास्तव में लागू नहीं होता है।

— harrymc

@harrymc मैं सकारात्मक हूं। @मौजूद है क्योंकि फ़ाइल मूल रूप से एक साझा नेटवर्क या पथ, बल्कि एक पत्र के साथ एक ड्राइव की तुलना में "से आया है"। इसलिए इसके बजाय DC[#].[whatever]अगर यह मूल रूप से Cड्राइव से आया था , तो आपको मिलता है D@[#].[whatever]... क्योंकि उस दूसरे चरित्र की स्थिति में जाने के लिए नेटवर्क साझा या UNC पथ में "ड्राइव अक्षर" नहीं है। (इसलिए यह @ड्राइव अक्षर के बजाय प्रतीक का उपयोग करता है ... जो भी कारण हो।)

— हॉपलेस

उनका कहना है कि एक्सेस थ्रू मैप्ड शेयर है, इसलिए उनके पास ड्राइव लेटर है। मैं उसकी समस्या का डुप्लिकेट करने की कोशिश कर रहा हूं और मैं इसे प्रबंधित नहीं कर सकता, मैप किया गया है या नहीं: फाइलें केवल हटा दी गई हैं। अजीब। क्या आप इसकी नकल कर सकते हैं? नए नामकरण सम्मेलन का उपयोग करने के लिए विकिपीडिया देखें $, @या नहीं #।

— harrymc

@harrymc मैं इसे कमांड पर डुप्लिकेट नहीं कर सकता, लेकिन मैं उपयोगकर्ताओं के रीडायरेक्ट किए गए प्रोफ़ाइल पथ में उन पर इस प्रकार की फ़ाइलों के साथ दर्जनों फ़ाइलवर्कर्स का प्रशासन करता हूं। एक मैप की गई ड्राइव स्थानीय रूप से संलग्न ड्राइव के समान नहीं है, क्योंकि नेटवर्क मैपिंग (और ड्राइव लेटर मैपिंग जो उनके साथ आती हैं) एक प्रति-उपयोगकर्ता सेटिंग हैं, न कि सिस्टम-वाइड सेटिंग। इसका मतलब यह है कि जब सिस्टम रीसायकल बिन मेनिफ़ेस्ट के लिए फ़ाइल का मूल स्थान लिखता है, तो वह वास्तविक पथ का उपयोग करता है , जैसे \\server1\Users\smithj\smithj's Documents\somefileकि उपयोगकर्ता द्वारा देखे जाने वाले पथ के बजाय Y:\somefile।

— होपलेस

मैंने इस जिज्ञासु समस्या पर कुछ और शोध किया, और अधिक जानकारी प्राप्त की जिसे मैंने एक अलग उत्तर में रखा।

— 21