मूल डेटा संरचना के रूप में हम (पदानुक्रमित) फ़ाइल सिस्टम से कैसे दुखी हो गए?

19

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

मुझे इसकी सरलता समझ में आती है, लेकिन आजकल ऐसा लगता है कि मूल रूप से अधिक विकल्प उपलब्ध हो सकते हैं। जहाँ तक मुझे पता है, फाइलसिस्टम की बुनियादी कार्यक्षमता को सुधारने का एकमात्र प्रोजेक्ट ReiserFS था, जहाँ आप बता सकते हैं कि किसी फ़ाइल की किस लाइन को किसके द्वारा और कब बदला गया था।

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

कुछ ऐसा होगा जो फाइल सिस्टम में किसी तरह का रिलेशनल फीचर होता है, जैसे कि आपको RDBMSes के साथ मिलता है। मैं समझता हूं कि यह विस्टा / 7 का हिस्सा होना चाहिए था, लेकिन यह फीचर लिस्ट से भी दूर हो गया।

निश्चित रूप से, कोई भी प्रोग्राम एक बाइनरी फ़ाइल को स्टोर कर सकता है और इसमें कोई भी डेटा संरचना है जिसे वह चाहता है, क्यों ओएस डेटा संग्रह के डेटा के साधारण उत्तराधिकार से परे, स्टोर करने के अधिक जटिल तरीकों की पेशकश नहीं कर सकता है?

language-agnostic operating-systems data-structures

— user1936
स्रोत

2

इसका मूल सरल होना चाहिए। आपके द्वारा उल्लिखित वैकल्पिक ब्लोट एक साधारण कोर के ऊपर जाना चाहिए। वैकल्पिक रूप से, दो दशकों तक प्रतीक्षा करें और कोई व्यक्ति फ़ाइल सिस्टम की धारणा को फिर से स्थापित करेगा।

— जॉब

3

"क्या होगा यदि वे पहले से ही असमान निर्देशिकाओं में मौजूद हैं, और उन्हें वहां रहने की आवश्यकता है?" कभी-कभी आप इस समस्या को हल करने के लिए कड़ी-कड़ी का उपयोग कर सकते हैं ...

— FrustratedWithFormsDesigner

1

इसके अलावा, इस विषय पर कुछ दिलचस्प पढ़ना: c2.com/cgi/wiki?FileSystemAlternatives

— FrustratedWithFormsDesigner

3

वास्तव में विंडोज 7 में एक समाधान नहीं है, लेकिन नई लाइब्रेरी आपको कुछ ऐसी कार्यक्षमता दे सकती हैं, जिनमें आप रुचि रखते हैं: lifehacker.com/#

— .5464350/…

1

अगर मैं एक बार में दो अलग-अलग फ़ोल्डरों में फाइल डालना चाहता हूं, तो मैं उस फाइल का शॉर्टकट एक में डाल देता हूं। नुकसान यह है कि यदि आप उस फ़ोल्डर / फ़ाइल को स्थानांतरित करते हैं, तो शॉर्टकट अमान्य होगा।

— मतीन उल्हाक

17

इसके साथ प्रारंभ करें: http://en.wikipedia.org/wiki/Unix_File_System

इसे पढ़ें: http://www.unix.org/what_is_unix/history_timeline.html

तो इसे पढ़ें: http://www.amazon.com/UNIX-Filesystems-Evolution-Design-Implementation/dp/0471164836

वहाँ एक सरल जवाब है "क्यों OS डेटा भंडारण के अधिक जटिल तरीकों की पेशकश नहीं कर सका, फाइलसिस्टम के सरल उत्तराधिकार से परे?"

क्योंकि यह ओएस के लिए बहुत अधिक है।

यही पुस्तकालयों और अनुप्रयोग पैकेजों के लिए हैं।

उदाहरण के लिए, ओरेकल आपको एक फ़ाइल-सिस्टम-जैसी सुविधाओं को बेचेगा, जो आप ओरेकल टूलसेट के साथ प्रबंधित करते हैं।

पायथन डीबीएम लाइब्रेरी का उपयोग बहुत ही परिष्कृत ऑन-डिस्क स्टोरेज संरचनाओं को बनाने के लिए करता है।

CouchDB और Mongo (और अन्य) बहुत परिष्कृत भंडारण संरचनाएं हैं जो कुछ डेटाबेस जैसी सुविधाओं की पेशकश करती हैं।

मुद्दा यह है कि ओएस को न्यूनतम करना चाहिए और सब कुछ एक ऐड-ऑन है।

— S.Lott
स्रोत

4

शांत सहमत। वास्तव में, ओपी के लिए जो कुछ भी पूछा जा रहा था, वह बहुत से मृत या मरने वाले WinFS प्रोजेक्ट में मौजूद है: en.wikipedia.org/wiki/WinFS । जितना गीक कहता है, 'नीट!' मुझ में अनुभवी उपयोगकर्ता और सॉफ्टवेयर इंजीनियर कहते हैं, "बहुत कठिन तरीका है!"

— एडम क्रॉसलैंड

6

"मुद्दा यह है कि ओएस को न्यूनतम करना चाहिए और सब कुछ एक ऐड-ऑन है।" एक ऐसे युग में एक साहसिक बयान को छोड़ दें जहां कुछ ऑपरेटिंग सिस्टम में एक अंतर्निहित विंडोिंग सिस्टम, फ़ाइल इंडेक्सिंग सेवा, मीडिया प्लेयर, रिमोट डेस्कटॉप, फ़ायरवॉल या नेट्रीस होते हैं।

— बिजिकलोप

1

@biziclop: सहमत। Windows ने लिनक्स दृष्टिकोण से विचलन किया है। वहां कुछ भी आश्चर्य नहीं हुआ।

— एस.लॉट

1

@ S.Lott मुझे गलत मत समझो, मैं आपके दृष्टिकोण से सहमत हूं, लेकिन विंडोज वैसे भी बहुत बेकार बकवास के साथ दुखी है, एक अतिरिक्त सुविधा से कोई फर्क नहीं पड़ेगा। :)

— बिज़लोप

4

वह यूनिक्स दर्शन है। यह सही नहीं है। यह करता है (और एक सी complier) यूनिक्स हार्डवेयर के लिए बंदरगाह के लिए आसान बनाते हैं। लोगों के लिए यह यूनिक्स को क्लोन करने के लिए भी काफी सरल बनाता है, जैसा कि हम आज पाते हैं। यदि कोई सुविधा उपयोगी है, और सभी कार्यक्रमों को इसकी आवश्यकता है, जैसे कहना, वर्तनी की जाँच इनपुट फ़ील्ड, तो रनटाइम वातावरण प्रदान करने में मूल्य है। हमें एक रिबन बार के 400 स्वतंत्र संस्करणों की आवश्यकता नहीं है।

— टिम विलिसक्रॉफ्ट

8

संक्षिप्त उत्तर है: हर दिन लोग फाइल सिस्टम को समझते हैं। यह उन्हें एक फाइल कैबिनेट की याद दिलाता है। वेब पेज और यहां तक कि फैट ऐप्स के बारे में सोचें, आपको क्यों लगता है कि Tabsयह बहुत लोकप्रिय है? लोग उनके साथ पहचान कर सकते हैं, और उन्हें जल्दी समझ सकते हैं।

संपत्ति के टैग के आधार पर फ़ाइल के लिए DB की खोज करने के लिए दादी को पढ़ाने की कोशिश करते हुए .. फ़ाइल सिस्टम के साथ, दादी को पता है कि फ़ाइल बस वह कहाँ रखी है ।

यहां तक कि WinFS के साथ भी मुझे नहीं लगता कि एमएस फाइल सिस्टम लुक और फील से छुटकारा पाने वाला था।

— बेवकूफों
स्रोत

9

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

— मैथ्यू पढ़ें

16

यह आपके लिए एक झटके के रूप में आ सकता है: हर रोज़ लोग फ़ाइल सिस्टम को नहीं समझते हैं। उन्हें विचारों का बेहोश होना नहीं है। और इसका मतलब यह नहीं है कि यूनिक्स शैली एफएस अपने माउंट पॉइंट्स, सिम्बलिंक्स और हार्डलिंक के साथ है, लेकिन इसमें फाइलों के साथ एक बोगी स्टैंडर्ड डायरेक्टरी स्ट्रक्चर है।

— biziclop

2

@ मॉरन्स, मेरी दादी को कभी नहीं पता कि वह कहां चीजें रखती हैं। जीमेल ने पहले ही मेरे वांछित प्रतिमान को एक टैगिंग सिस्टम में स्थानांतरित कर दिया है, विशेष रूप से स्वचालित रूप से चीजों को टैग करने के लिए फ़िल्टर के साथ। मुझे लगता है कि फाइलसिस्टम प्रतिमान प्रोग्रामिंग ट्री-संरचनाओं की सादगी के कारण बड़े पैमाने पर लागू किया गया था। यह प्रोग्रामिंग के नजरिए से भी संबोधन को आसान बनाता है। आप टैग-आधारित प्रणाली में दस्तावेज़ का स्थान कैसे निर्दिष्ट करेंगे? यह नहीं कहा जा सकता है कि नहीं किया जा सकता है, लेकिन विवरणों का लोहा होना चाहिए।

— zzzzBov

3

क्या आप कैबिनेट के संचालन के लिए आवश्यक हजारों फ़ोल्डरों और दस्तावेजों से भरी अपनी फाइल कैबिनेट खरीद लेते हैं, जिसे आपको अपने आसपास और आसपास नेविगेट करना चाहिए, लेकिन स्पर्श करने के लिए सावधान रहना चाहिए? क्या आपकी फ़ाइल कैबिनेट हर बार जब आप ड्रॉअर को बाहर निकालती हैं तो एक अलग स्थान पर खुलती है? आदि आदि मैं मैथ्यू और बिज़लोप से सहमत हूँ - "एवरीडे" लोग इसे प्राप्त नहीं करते हैं।

— निकोल

2

मेरे पास सीएस की डिग्री है। लेकिन मुझे नहीं पता कि कौन से फ़ोल्डर में कोई भी विंडोज़ किस फाइल को डालती है। विशेष रूप से डेस्कटॉप, StartMenu, QuickLaunch, और अन्य सभी उपयोगकर्ता / सिस्टम विशिष्ट डिफ़ॉल्ट फ़ोल्डर। (वह M $ -Help सिस्टम मुझे यह समझाने में मदद नहीं करता है कि एक बटन कैसे दबाया जाए।) मुझे अपनी खुद की फ़ाइलों की खोज करने में सक्षम होने के लिए CygWin को स्थापित करने की आवश्यकता है, क्योंकि नए M $ खोज सुविधाओं में सरल मौजूदा फ़ाइलें अब और नहीं मिलती हैं win2k पर। छिपाना-सिस्टम-फाइल, छिपाना-फ़ाइल-एक्सटेंशन जैसे मिसफिटर्स को अक्षम करना अब ज्यादातर समस्याओं का समाधान नहीं करता है। जब मैंने (बिल्कुल नया) winXP पर काम करने के लिए मजबूर किया, तो मैंने विंडोज़ छोड़ दिया।

— कोमोनड

6

यहाँ हर उत्तर में थोड़ी सच्चाई है लेकिन मुझे नहीं लगता कि यह पूरी सच्चाई है।

आप जो सूचीबद्ध करते हैं, वे ज्यादातर ऐसी विशेषताएं हैं जो उपयोगकर्ताओं और डेवलपर्स द्वारा समान रूप से हर दिन याद की जाती हैं।

लोग पेड़-आधारित फ़ाइल प्रणाली को किसी भी तरह से नहीं समझते हैं जितना वे एक डीएजी-आधारित को समझेंगे।

और एक्सटेंशन नामक फ़ाइल नामों के दयनीय उपांगों के लिए बिल्कुल कोई बहाना नहीं है। वे न केवल अपने उद्देश्य (फ़ाइल प्रकार की पहचान) के लिए पूरी तरह से अनुपयुक्त हैं, बल्कि उपयोगकर्ताओं के लिए उपद्रव का एक अंतहीन स्रोत भी हैं।

हम अभी भी उनका उपयोग कर रहे हैं, इसका कारण यह है कि "यह करेंगे" रवैया और पुराने कोड के साथ संगतता बनाए रखने की वास्तविक आवश्यकता है। फ़ाइलों को संग्रहित करने के लिए एक नया दृष्टिकोण का अर्थ होगा मूल फ़ाइल I / O API में आमूल-चूल परिवर्तन, जो मौजूदा मौजूदा कोड को बेकार कर देगा। या तो वह या आपको उनके आसपास टिप करना होगा, विरासत एपीआई को बनाए रखना होगा। PROGRA ~ 1 याद रखें।

मुझे लगता है कि उपरोक्त कारणों से, हालांकि भविष्य में विशेष अनुप्रयोगों के लिए अधिक विशिष्ट फ़ाइल सिस्टम हो सकता है, लेकिन जब डेस्कटॉप और लैपटॉप पीसी आर्किटेक्चर वर्तमान में जीवित रहते हैं, तो हम मेटाडेटा की कमी के साथ बड़े पैमाने पर ट्री-आधारित फ़ाइल सिस्टम के साथ फंस जाते हैं और इसके भयानक छोटे विस्तार।

अब मैं पक्षों को बदलने जा रहा हूं।

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

अभी तक सभी ऑपरेशन सीधे हैं, कुछ दूरी पर कोई डरावना कार्रवाई नहीं है, कुछ भी नहीं जो मुझे wtf बना देगा।

दरअसल, मैंने एक बार अमीर मेटाडेटा और एक DAG- आधारित पदानुक्रम के साथ एक दस्तावेज़ स्टोर लागू किया था। (यह एक फ्री-फॉर्म डीएजी भी नहीं था, यह कड़ाई से दो-स्तरीय मेटास्टस्ट्रक्चर और दस्तावेज थे, जो कि एक स्तर 1 या स्तर 2 संग्रह के बच्चे हो सकते हैं। इसलिए यह वास्तव में सरल है।)

जाहिर है, आवश्यकता है कि एक संग्रह के भीतर दस्तावेज़ के नाम अद्वितीय होने चाहिए।

और फिर समस्याओं का प्रवाह शुरू हो गया। क्या होगा अगर आप एक संग्रह खोलते हैं और दस्तावेज़ का नाम बदलकर कुछ ऐसा करते हैं जो एक अलग संग्रह में टकराता है जो दस्तावेज़ भी है? हमने एक त्रुटि संदेश प्रदर्शित किया लेकिन उपयोगकर्ता पूरी तरह से चकरा गए। (ये वही उपयोगकर्ता हैं जिन्होंने इस आवश्यकता के लिए कहा था।)

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

आखिरकार हमने हार मान ली, सौभाग्य से समय अभी भी है।

अतिरिक्त खोज पहलुओं ने मेटाडेटा को संभव बनाया हालांकि एक पूर्ण इलाज किया।

— biziclop
स्रोत

5 एमबी हार्ड ड्राइव पर रिमेम्ब्र सीपी / एम? अतीत को स्क्रॉल करते हुए सैकड़ों और सैकड़ों फाइलें। भयानक!

— जल्दी_अगले

@quickly_now आह, अच्छे पुराने सीपी / एम। :)

— बिज़िक्लोप

3

ईमानदार होने के लिए, मैं मैक पर अपनी फाइलों पर मुश्किल से मेटाडेटा को छूता हूं। मुझे लगता है कि OSX (जो टिप्पणियों और इसके बाद का समर्थन करता है) का उपयोग करने के पिछले 5 वर्षों में, मैंने शायद 2 फाइलों पर मेटाडेटा का उपयोग किया है। नहीं कह रहा है यह एक बुरा विचार है।

मुझे यकीन नहीं है कि टैगिंग का ओवरहेड मेरे लिए कैसे व्यावहारिक है।

मुझे लगता है कि मुझे पता है कि सबसे अच्छी फाइल सिस्टम सुविधा एक फाइल सिस्टम स्तर संस्करण प्रणाली होगी ... जो क्रॉस विभाजन का काम करती है। यह 70 और 80 के दशक की शुरुआत में वैक्सन पर किया गया था, यह सुनिश्चित नहीं था कि यह यूनिक्स और एनटीएफएस / विंडोज के साथ क्यों नहीं पकड़ा गया।

— पॉल नाथन
स्रोत

NTFS / Windows के आधुनिक संस्करण संस्करण प्रदान करते हैं। यह बिल्कुल आपके चेहरे में नहीं है, लेकिन यह मौजूद है। हालांकि यह वीएमएस की तुलना कैसे करता है कह नहीं सकता।

— Shog9

2

मैंने पुराने मिनिसल्स जैसे HP3000 और एनकोर / गोल्ड पर गैर-पदानुक्रमित फ़ाइल सिस्टम के साथ काम किया है। आपके पास निर्देशिका नहीं थी; आप एक समूह और एक खाता था, और फ़ाइलों "के रूप में नामित किया गया समूह । खाते । फ़ाइल " users.jbode.myfile1 "," dev.jbode.main ", आदि जैसे",

अब, ये पुराने सिस्टम हैं, जहां व्यक्तिगत डिस्क स्पेस कोटा सिंगल मेगाबाइट में थे, इसलिए ऐसा नहीं है कि आपको अपने सामान को व्यवस्थित करने के लिए बहुत अधिक स्तरों की आवश्यकता है, लेकिन एक उपयोगकर्ता और प्रोग्रामर के दृष्टिकोण से पदानुक्रमित सिस्टम बहुत अच्छे हैं।

— जॉन बोडे
स्रोत

1

मैं नहीं देखता कि कम से कम (कम से कम कुछ) वर्तमान फ़ाइल सिस्टम को टैग का समर्थन करने के लिए वास्तव में बहुत कुछ करने की जरूरत है [संपादित करें: कुछ भी, ईमानदार होना]। जब आप इसे करने के लिए नीचे लाने के लिए, जुड़े कुछ अतिरिक्त डेटा से थोड़ा अधिक टैग साधन समर्थन के साथ एक फ़ाइल है, लेकिन बाइट्स की धारा में लिखा है के लिए है कि फाइल।

NTFS ( व्यापक उपयोग में एक उदाहरण को चुनने के लिए) वह ठीक कर सकता है: जहाँ तक NTFS की परवाह है, एक फाइल जरूरी नहीं कि बाइट्स की एक भी धारा हो। NTFS पर आप एक एकल फ़ाइल नाम के साथ डेटा की मनमानी संख्या को जोड़ सकते हैं। प्रत्येक फ़ाइल में एक (संभवतः रिक्त) "प्राथमिक स्ट्रीम" है जिसमें कोई नाम नहीं है। हालाँकि, यह अन्य धाराओं की एक मनमानी संख्या हो सकती है, जिनमें से प्रत्येक का एक नाम होना चाहिए। इसका उपयोग करते हुए, किसी मौजूदा फ़ाइल में "उदाहरण के लिए" (केवल उदाहरण के लिए) "टैग" जोड़ना सही मायने में तुच्छ होगा , और (स्पष्ट रूप से पर्याप्त) अपने टैग को उस स्ट्रीम में लिखें।

उसके बाद कुछ हद तक कठिन हिस्सा आता है: आपके टूल को आपके द्वारा वहां लगाए गए टैग का उपयोग करने के लिए प्राप्त करना। आदर्श रूप से, आप संभवतः उन्हें तेज़ी से खोज करने के लिए अनुक्रमित करना चाहेंगे, इसलिए आप विशिष्ट टैग के साथ सभी फ़ाइलों की "वर्चुअल निर्देशिका" बनाने जैसे कार्य कर पाएंगे।

कम से कम मेरे दृष्टिकोण से, फ़ाइल सिस्टम में पहले से ही क्या आवश्यक है, हालांकि - यह डेटा को स्टोर और पुनर्प्राप्त करने के लिए माना जाता है, और यह अभी पूरी तरह से ठीक कर सकता है। उस डेटा का उपयोग करना अन्य उपकरणों का काम है। वे उपकरण वर्तमान में मौजूद नहीं हैं, लेकिन उनका समर्थन करने के लिए फ़ाइल सिस्टम अवसंरचना।

अगर मुझे एक पल के लिए भी सनकी होने दिया जाए, तो मैं कहूंगा कि यह अपरिहार्य था कि NTFS की यह विशेषता लगभग पूरी तरह से अनदेखा और अज्ञात रहेगी। आखिरकार, यह उपयोग करने के लिए सरल है और इसके लिए किसी विशेष एपीआई या किसी अन्य चीज की आवश्यकता नहीं है। आप इसे पूरी तरह से पोर्टेबल सी, सी ++, या कुछ और में उपयोग कर सकते हैं जो आपको एक मनमाना फ़ाइल नाम निर्दिष्ट करने देगा। AFS के साथ एक फ़ाइल बनाने के लिए एक त्वरित बिट कोड प्रदर्शित करना है:

#include <fstream>

int main() {
    std::ofstream out("test.txt");
    std::ofstream tag("test.txt:tags");

    out << "This is the output file";
    tag << "tag1 tag2";

    return 0;
}

और, यहां टैग्स को पढ़ने और प्रदर्शित करने के लिए कुछ कोड दिए गए हैं:

#include <fstream>
#include <iterator>
#include <iostream>
#include <string>

int main() { 
    std::ifstream tags("test.txt:tags");

    std::copy(std::istream_iterator<std::string>(tags),
          std::istream_iterator<std::string>(),
          std::ostream_iterator<std::string>(std::cout, " "));
    return 0;
}

सभी बहुत सरल और आसान। ध्यान दें कि यद्यपि मैंने केवल डेटा का एक छोटा सा हिस्सा लिखा है, आप किसी भी अन्य फ़ाइल की तरह ही एएफएस का इलाज कर सकते हैं - सभी सामान्य "सामान" कुछ और की तरह ही काम करते हैं। एक सामान्य निर्देशिका प्रदर्शन में, वह सब दिखाई देगा जो प्राथमिक स्ट्रीम है (उदाहरण के लिए, फ़ाइल के लिए दिखाया गया आकार प्राथमिक स्ट्रीम का आकार होगा), लेकिन यदि आप इसे देखना चाहते हैं, तो वैकल्पिक धाराओं के बारे में भी जानकारी दिखा dir सकते हैं /Rझंडे के साथ । उदाहरण के लिए, ऊपर बनाई गई फ़ाइल की सूची इस तरह दिखती है:

03/16/2011  08:22 PM                23 test.txt
                                     9 test.txt:tags:$DATA
               1 File(s)             23 bytes

— जेरी कॉफ़िन
स्रोत

1

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

— जल्दी_अगले

हां, मैंने देखा है कि अधिकांश NAS सिस्टम बल्कि ... को चुनौती दी गई है (और यह एकमात्र तरीका भी नहीं है)। वास्तविक बैकअप के लिए और चीजों के प्रकारों को बहाल करने के लिए, यह एक समस्या का कारण नहीं बनता है (कम से कम यदि प्रश्न में सॉफ़्टवेयर सक्षम रूप से लिखा गया है): BackupReadसभी स्ट्रीमों BackupWriteको अनुक्रमित करेगा , और फ़ाइल को (वैकल्पिक धाराओं के साथ) पुनर्गठित करेगा क्रमबद्ध प्रारूप।

— जेरी कॉफिन

निर्भर करता है कि क्या आप चाहते हैं कि एनएएस पर बैकअप की जाने वाली फाइलें सीधे पढ़ने योग्य हों। यदि आप करते हैं (और विशेष पुनर्स्थापना कार्यक्रमों की आवश्यकता से बचते हैं) तो आप सादे-ओले फ़ाइलों के साथ फंस जाते हैं।

— जल्दी_अगले