, तथा इसके बाद के संस्करणों  2000,  ,   2003,   2008,   और  7 की मानक फ़ाइल प्रणाली है.

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

 इतिहास 
1980 के दशक के मध्य में,  और  ने आने वाली पीढ़ी के लिए चित्रमय ऑपरेटिंग सिस्टम बनाने के लिए एक संयुक्त परियोजना का गठन किया। इस परियोजना के परिणामस्वरूप 2, बना, लेकिन  और  कई महत्वपूर्ण मुद्दों पर असहमत हो जाने की वजह से अलग हो गए। 2  की एक परियोजना बना रहा।  ने   पर काम शुरू कर दिया। 2 फ़ाइल प्रणाली  में कई महत्वपूर्ण नई सुविधायें थीं। जब  ने अपना नया ऑपरेटिंग सिस्टम बनाया, उन्होनें  के लिए इन में से कई अवधारणाओं का प्रयोग किया। . शायद एक ही स्रोत से उत्पन्न होने के परिणामस्वरूप,  और  डिस्क विभाजन की पहचान के लिए एक ही कोड टाइप (07) का प्रयोग करते हैं। एक ही  का एक साथ प्रयोग करना असामान्य है क्योंकि दर्जनों कोड उपलब्ध थे और अन्य प्रमुख फ़ाइल प्रणालियों के अपने कोड हैं।  के नौ से ज्यादा कोड हैं (12, 16, 32, आदि के लिए अलग अलग). एल्गोरिदम, जो विभाजन प्रकार 07 में फ़ाइल प्रणाली की पहचान करती है, को अतिरिक्त जांच करनी चाहिए। यह भी स्पष्ट है कि  ने अपने स्थापत्य डिजाइन का कुछ भाग  द्वारा प्रयुक्त की जाने वाली फ़ाइल-11 से लिया है। यह शायद ही आश्चर्य की बात है क्योंकि डेव कटलर  और  , दोनों पर काम कर रहे मुख्य व्यक्ति थे।

 संस्करण 
 ने पांच संस्करण जारी किये हैं:

  3.1 का 1.0, 1993 के मध्य में जारी हुआ 
  3.5 का 1.1, 1994 में जारी हुआ 
 3.51  का 1.2 (1995 के मध्य में) और  4 (1996 के मध्य में)(कभी कभी " 4.0" के रूप में जाना जाता है, क्योंकि  संस्करण 4.0 है) 
  2000 का 3.0 (" 5.0") 
   का 3.1 ( 2001;" 5.1"),  2003( 2003; कई बार " 5.2" के रूप में जाना जाता है), (2005 के मध्य में;)(कई बार " 6.0" के नाम से जाना जाता है) तथा   2008

1.0 और 1.1(और इससे नए संस्करण) आपस में मेल नहीं खाते अथार्त् 3.5  द्वारा लिखित संस्करण  3.1 द्वारा तब तक नहीं पढ़ा जा सकता जब तक कि  3.1 को  3.5 सीडी द्वारा अपडेट न किया जाए, जिसमें  बड़े फ़ाइल नाम की सुविधा भी उपलब्ध है। 
1.2 कम्प्रेस्ड फ़ाइलों, मुद्दों तथा  आधारित सुरक्षा इत्यादि के लिए सहायक है। 
3.0 में डिस्क कोटा, एन्क्रिप्शन, स्पार्स फ़ाइल, रीपार्स पॉइंट्स, अपडेट क्रम संख्या () व्यवस्था,  एक्सटेंड फ़ोल्डर और उसकी फ़ाइलें और पुनर्गठित सुरक्षा डिस्क्रिप्टर्स को जोड़ा गया ताकि सारी फ़ाइलें जो सुरक्षा की एक जैसी तकनीक का प्रयोग करती हैं, एक ही डिस्क्रिप्टर का सांझा प्रयोग कर सकें. 
3.1 ने अनुपयोगी  रिकॉर्ड संख्या के स्थान पर मास्टर फ़ाइल तालिका () की प्रविष्टियों का विस्तार किया (जो क्षतिग्रस्त  फाइलें ठीक करने में उपयोगी है).

  ने ट्रांसेक्शनल ,  प्रतीकात्मक लिंक, विभाजन (पार्टीशन) के संकुचन और स्वयं-उपचार की सुविधा को पेश किया, हालांकि ये सुविधायें फ़ाइल सिस्टम से अधिक ऑपरेटिंग सिस्टम की अतिरिक्त कार्यक्षमता से सम्बंधित हैं।

 विशेषताएँ 
 3.0 अपने पूर्ववर्तियों के अपेक्षाकृत कई नई सुविधाओं से लैस है:स्पार्स फ़ाइल सुविधा, डिस्क कोटा का उपयोग, रीपार्स पॉइंट, वितरित लिंक ट्रैकिंग और फ़ाइल स्तर एन्क्रिप्शन जिसे एनक्रिप्टिंग फ़ाइल सिस्टम () के नाम से भी जाना जाता है।

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

यह  की एक महत्वपूर्ण कार्यक्षमता है जो (एक विशेषता जो 32 प्रदान नहीं करते) यह सुनिश्चित करने के लिए है कि इसका आंतरिक जटिल डाटा (खासकर वोल्यूम आवंटन बिटमैप, या डाटा स्थानांतरित करने के लिए डिफ्रेगमेन्टेशन ,  रिकॉर्ड में संशोधन जैसे कि  रिकॉर्ड में संग्रहित कुछ वेरिएबल व एट्रीब्यूट सूची, या शेयर किए गए सुरक्षा डिस्क्रिप्टर्स में कुछ अपडेट, या बूट सेक्टर व इसकी प्रतिलिपि फ़ाइल जहाँ वोल्यूम पर  की आखिरी गतिविधि संग्रहित है) तथा सूची (डायरेक्टरी तथा सुरक्षा डिस्क्रिप्टर्स के लिए) सिस्टम के क्रैश (दुर्घटनाग्रस्त) होने की स्थिति में यथावत बने रहेंगे तथा वोल्यूम को दोबारा ठीक करने के दौरान इन महत्त्वपूर्ण डाटा संरचनाओं को फिर से उपलब्ध कराएंगे.

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

 हार्ड लिंक और लघु फ़ाइल नाम 
मूल रूप से      4.0 रिसोर्स गाइड, " कम्पेटिबिलिटी"  में  उपतंत्र में शामिल होने वाले हार्ड लिंक डायरेक्टरी जंक्शन के समान हैं, लेकिन डायरेक्टरी के बजाए फ़ाइलों के लिए प्रयुक्त होते हैं। हार्ड लिंक केवल उसी वोल्यूम की फ़ाइलों में लागू हो सकते हैं क्योंकि फ़ाइल के  रिकार्ड में अतिरिक्त फ़ाइल नाम का रिकॉर्ड जुड़ा हुआ है। लघु (8.3) फ़ाइल नाम भी अतिरिक्त फ़ाइल नाम रिकॉर्ड की तरह क्रियान्वित होते हैं जिनकी अलग से डायरेक्टरी प्रविष्टियाँ नहीं हैं।

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

मैलवेयर वैकल्पिक डाटा स्ट्रीम का इस्तेमाल अपने कोड को छिपाने के लिए करते हैं;मालवेयर अन्य डाटा स्ट्रीम का प्रयोग करते हैं? ,   , 21 अगस्त 2007 कुछ मैलवेयर स्कैनर और अन्य विशेष उपकरण अब वैकल्पिक स्ट्रीम में डाटा की जाँच करते हैं।

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

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

 स्पार्स फ़ाइलें 
स्पार्स फ़ाइलें ऐसी फ़ाइलें हैं जिनमें स्पार्स डाटा सेट होता है तथा डाटा ज्यादातर शून्य से भरे होते हैं। डाटाबेस प्रोग्राम कभी कभी स्पार्स फ़ाइलों का उपयोग करते हैं।स्पार्स फ़ाइल त्रुटियाँ: 1450 या 665 फ़ाइल विखंडन के कारण : सुधार और कार्य ,  ग्राहक सेवा और सहायता ()  सर्वर इंजीनियर्स ब्लॉग, 4 मार्च 2009 इस कारण,  ने स्पार्स फ़ाइलों के कुशल संग्रहण के लिए एक प्रोग्राम को खाली (ज़ीरो) डाटा क्षेत्रों को निर्दिष्ट करने की अनुमति दी है। एक प्रोग्राम स्पार्स फ़ाइल को सामान्य तरीके से पढ़ता है तथा फ़ाइल सिस्टम यह गणना करता है कि फ़ाइल ऑफसेट पर क्या डाटा वापिस आना चाहिए। कंप्रेस फ़ाइलों के साथ, कोटा सीमा के निर्धारण के समय स्पार्स फ़ाइलों के वास्तविक साइज़ का ध्यान नहीं रखा जाता.

 फ़ाइल कंप्रेशन 
 77 एल्गोरिथ्म के एक संस्करण का प्रयोग कर के फ़ाइलों को कंप्रेस (लोकप्रिय ज़िप फ़ाइल प्रारूप में भी प्रयुक्त होता है) कर सकता है। हालांकि कंप्रेस फ़ाइलों को पढ़ने-लिखने की पहुँच पारदर्शी है,  सर्वर सिस्टम तथाया रो़मिंग प्रोफाइल के साथ नेटवर्क शेयर पर कंप्रेशन की अनुशंसा नहीं करता क्योंकि यह प्रोसेसर पर भारी बोझ डालता है।" में  कंप्रेशन के लिए सर्वोत्तम अभ्यास."   ज्ञान आधार  18-08-2005 को लिया गया।

सीमित हार्ड डिस्क स्थान के साथ एक सिंगल यूज़र सिस्टम शायद  कंप्रेशन का सफलतापूर्वक प्रयोग करेगा. एक कंप्यूटर में धीमी कड़ी  नहीं बल्कि हार्ड ड्राइव की गति है, इसलिए  कंप्रेशन स्थान तथा (अक्सर) गति के रूप में सीमित, बेहतर प्रयोग के लिए धीमी गति से संग्रहण करता है।  कंप्रेशन स्पार्स फ़ाइलों का भी स्थान ले सकता है जब एक प्रोग्राम (उदाहरण - एक  ) स्पार्स फ़ाइलों की सामग्री के बिना फ़ाइलें नहीं बना सकता.

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

 ट्रांसेक्शनल  
  में, प्रोग्राम के द्वारा फ़ाइलों में होने वाले सामूहिक परिवर्तनों को ट्रांसेक्शन में परिवर्तित करने के लिए ट्रांसेक्शनल  का प्रयोग कर सकते हैं। ट्रांसेक्शन सभी परिवर्तनों के होने या न होने की गारंटी देता है तथा यह भी गारंटी देता है कि बिना प्रतिबद्धता के ट्रांसेक्शन के बाहर कोई परिवर्तन नहीं होगा। 

यह वोल्यूम शैडो कॉपी (अथार्त् कॉपी-ऑन-राइट) में प्रयुक्त होने वाली तकनीकें प्रयुक्त करता है ताकि ओवरराइट किया गया डाटा सुरक्षित ढंग से वापिस लाया जा सके, तथा बिना प्रतिबद्धता वाली अथवा प्रतिबद्ध हो चुकी किन्तु पूरी तरह क्रियान्वित न होने वाली ट्रांसेक्शन को  जर्नल लॉग चिन्हित कर ले (क्रियान्वन के दौरान किसी प्रतिभागी द्वारा सिस्टम क्रैश होने की स्थिति में).

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

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

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

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

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

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

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

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

 वोल्यूम माउंट पॉइंट 
 माउंट पॉइंट की तरह है, जहां एक फ़ाइल सिस्टम का मूल एक डायरेक्टरी से जुड़ा हुआ है।  में, यह एक अतिरिक्त फ़ाइल सिस्टम को, बिना किसी ड्राइव अक्षर (जैसे : या :) के, बढ़ने की अनुमति देता है। 

एक बार वोल्यूम के दूसरे वोल्यूम की मौजूदा डायरेक्टरी के ऊपर कॉपी होने की स्थिति में उस डायरेक्टरी की पिछली सामग्री अदृश्य हो जाती है माउंट किये गये वोल्यूम की रूट डायरेक्टरी से बदल जाती है। माउंट होने वाला वोल्यूम के पास फिर भी स्वयं द्वारा घोषित ड्राइव अक्षर हो सकता है। फ़ाइल सिस्टम कभी भी वोल्यूम को एक दूसरे के ऊपर माउंट करने की अनुमति नहीं देते. वोल्यूम माउंट पॉइंट को लगातार (सिस्टम रिबूट के बाद स्वत: रिमाउंट हो जाता है) या नहीं बनाया जा सकता है।

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

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

डायरेक्टरी लगातार जुड़ती है (जिसे     निर्देश के साथ बनाया जा सकता है तथा कन्सोल प्रोम्प्ट से   निर्देश द्वारा हटाया जा सकता है) तथा सर्वर पर हल होती है क्योंकि वे स्थानीय सिस्टम या डोमेन, जिस पर पेरेंट वोल्यूम माउंट है, के समान सुरक्षा क्षेत्र को बांटते हैं तथा लक्ष्य डायरेक्टरी की सामग्री के अनुसार अपनी सामग्री की सुरक्षा व्यवस्था करते हैं, हालाँकि जंक्शन की अलग सुरक्षा व्यवस्था हो सकती है। एक डायरेक्टरी जंक्शन का लिंक हटने पर लक्ष्य डायरेक्टरी की फ़ाइलें नष्ट नहीं होतीं.

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

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

 सिम्बोलिक (प्रतीकात्मक) लिंक 
सिम्बोलिक लिंक्स(या सॉफ्ट लिंक)   में शुरू किए गए थे। सिम्बोलिक लिंक्स ग्राहक छोर पर हल किये जाते हैं। इसलिए, जब एक सिम्बोलिक लिंक सांझा किया जाता है, तो लक्ष्य ग्राहक के पहुँच प्रतिबंधों के अधीन है, न कि सर्वर के.

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

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

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

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

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

 मिल कर कार्य करने की क्षमता 
इसके क्रियान्वन के लिए कोई विवरण जारी नहीं किया गया जिस से तीसरे पक्ष के विक्रेताओं के लिए  को सँभालने के टूल उपलब्ध कराना मुश्किल बना दिया।

  
 को पढ़ने और लिखने की क्षमता -3 जी ड्राईवर द्वारा प्रदान की गई है। यह ज्यादातर  वितरण में शामिल है। अन्य पुराने और ज्यादातर केवल पढ़ने के समाधान भी मौजूद हैं:

   2.2 :  संस्करण 2.2.0 और बाद में  विभाजन पढ़ने की क्षमता शामिल है। 
   2.6:  संस्करण 2.6.0 और बाद में एक ड्राईवर एंटोन अलतापर्माकोव (कैम्ब्रिज विश्वविद्यालय) और रिचर्ड रुस्सों द्वारा लिखा गया। यह फ़ाइल को पढ़ने, ओवरराइट करने तथा साइज़ बदलने में सहायता करता है। 
 : एक पढ़नेलिखने वाला यूज़र स्पेस ड्राईवर. यह फ़ाइल कंप्रेशन व कूटबद्ध लेखन, फ़ाइल के स्वामित्व में परिवर्तन और उपयोग के अधिकार को छोड़कर  को पढ़ने-लिखने की सुविधा प्रदान करता है। 
  के लिए : एक कमर्शियल ड्राईवर जिसे  द्वारा पढ़नेलिखने की सुविधा उपलब्ध है। 
 कैप्टिव : एक '' ड्राइवर है जो  का अपना ड्राइवर, . का प्रयोग करता है।

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

 मैक   
मैक   10.3 और बाद के संस्करणों में  द्वारा फॉर्मेट किये गये पार्टीशन को केवल पढ़ने की क्षमता है।  द्वारा लाइसेंस प्राप्त -3 भी  के माध्यम से मैक   पर काम करता है तथा  विभाजन पर पढ़ने तथा लिखने की अनुमति देता है। मैक   के लिए एक साथ पढ़नेलिखने का अधिकार प्राप्त करने का एकमात्र उपाय "मैक   के लिए पैरागोन " है।  पर लिखने में सहायक प्रोग्राम मैक   10.6 में पाया गया है, लेकिन 10.6.1 संस्करण में सक्रिय नहीं किया गया है, हालांकि क्रियान्वित करने के लिए  मौज़ूद हैं।

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

उदाहरण के लिए, एक ऑपरेटिंग सिस्टम, जो सहायक नहीं है, पर  पार्टीशन पर पिछला संस्करण (अथार्त वोल्यूम शैडो कॉपी) प्राप्त करने की कोशिश करने के परिणामस्वरूप पिछले संस्करण की सामग्री खो जायेगी.

 अन्य 
, , , और  केवल पढ़ने के लिए  स्पोर्ट देते हैं (बीटा  ड्राईवर  को लिखनेमिटाने की अनुमति देता है, लेकिन आमतौर पर असुरक्षित माना जाता है). एक अन्य तीसरा उपकरण , जो -3 पर आधारित था,  के लिए पढ़ने और लिखने की अनुमति देता है। -3  भी  के माध्यम से  के अलावा मैक  , , ,  और  पर काम करती है। एक मुफ्त निजी प्रयोग के लिए पढ़नेलिखने का - का ड्राईवर "4" भी मौजूद है।

  से संगतता (कम्पेटिबिलिटी) 
 वर्तमान में एक उपकरण (.) प्रदान करता है जो (केवल   3 पर),16  2000 और उच्च संस्करण और 32 को  में बदल देता है, लेकिन इसका कोई दूसरा तरीका नहीं है। विभिन्न तीसरी पार्टी उपकरण भी सुरक्षित  पार्टीशन रीसाइज़िंग में सक्षम हैं।  ने   में पार्टीशन को सिकोड़ने तथा बड़ा करने की क्षमता जोड़ी है, लेकिन यह क्षमता सीमित है क्योंकि यह पेज फ़ाइल फ्रेग्मेंट्स या स्थानांतरित न होने वाली फ़ाइल को नहीं हटाएगा, अतः पार्टीशन को सिकोड़ने की क्षमता सीमित है। एक पेज फ़ाइल के बिना रीबूटिंग या डीफ्रेगमेंट करने के लिए किसी तीसरे टूल का उपयोग स्थिति को खराब कर सकता है यदि पेज फ़ाइल हटने वाली फ़ाइल नहीं है।

ऐतिहासिक कारणों से,  के संस्करण जोकि  का समर्थन नहीं करते, सभी आंतरिक रूप से समय को स्थानीय समय क्षेत्र के रूप में रखते हैं और  के अलावा बाकी फ़ाइल सिस्टम भी ऐसा ही करते हैं जिन्हें  का वर्तमान संस्करण सहायता कर रहा है। तथापि,   और आने वाले संस्करण  के रूप में आंतरिक टाइम स्टाम्प्स रखते हैं और प्रदर्शन के लिए उपयुक्त परिवर्तन करते हैं। इसलिए,  में  टाइम स्टाम्प्स हैं। इसका मतलब यह है कि जब फाईलें  और नॉन- पार्टीशन के बीच कॉपी या स्थानांतरित की जाती है, तो  को फ्लाई पर टाइम स्टाम्प्स बदलने की आवश्यकता पड़ती है। लेकिन अगर कुछ फ़ाइलें जब डे-लाइट सेविंग टाइम() के अंतर्गत स्थानांतरित की जाती हैं और अगर कुछ फ़ाइलें मानक समय के अंतर्गत स्थानांतरित की जाती हैं तो रूपांतरण के दौरान विसंगतियां हो सकती हैं। परिणामस्वरूप, किसी एक दिन बाद जब स्थानीय समय क्षेत्र बदलता है, यूज़र यह जान सकते हैं कि कुछ फाईलों के टाइम स्टाम्प्स में 1 घंटे की गलती है। डीएसटी को लागू करने में उत्तरी और दक्षिणी गोलार्द्धों के बीच मतभेद के चलते, किसी भी 12 महीने में एक संभावित टाइमस्टैम्प में 4 घंटे तक की त्रुटि हो सकती है।बीटिंग द डे-लाइट सेविंग टाइम बग  तथा फ़ाइल का सुधार समय सही करना "द कोड प्रोजेक्ट"

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

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

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

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

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

क्षेत्र संख्या फ़ाइल का नाम उद्देश्य: 0      वोल्यूम पर सभी फाइलों का वर्णन, जिसमें फ़ाइल नाम, टाइम स्टांप, स्ट्रीम के नाम शामिल है और क्लस्टर की संख्या जहां डाटा स्ट्रीम रहते हैं, इंडेक्स, सुरक्षा को पहचानने के कारक और फ़ाइल गुण जैसे 'केवल पढ़ने","संकुचित","एन्क्रिप्टेड ", इत्यादि.  1     पहली महत्वपूर्ण प्रविष्टियों का डुप्लीकेट   है, आमतौर पर 4 प्र्विशितियाँ होती हैं 4 .  2     फ़ाइल सिस्टम मेटाडाटा का ट्रांसेक्शन लॉग रखती है।  3     वोल्यूम के बारे में जानकारी, अर्थात् वोल्यूम ऑब्जेक्ट पहचानकर्ता,वोल्यूम लेबल, फ़ाइल सिस्टम संस्करण और वॉल्यूम फ्लैग्स (स्थापित,  अनुरोध,  आकार परिवर्तन का अनुरोध,  4 पर स्थापना, वोल्यूम क्रम संख्या को अपडेट करना, संरचना अपडेट करने का अनुरोध). यह डाटा एक डाटा स्ट्रीम में संग्रहीत नहीं है, बल्कि विशेष  विशेषताओं में: यदि उपस्थित हों,  रिकॉर्ड में वोल्यूम ऑब्जेक्ट  संग्रहित है;  रिकॉर्ड में वोल्यूम लेबल संग्रहीत है और शेष वोल्यूम डाटा  रिकॉर्ड में है। नोट: वोल्यूम क्रम संख्या बूट (नीचे) फ़ाइल में संग्रहित है।  4      गुणों की एक तालिका है जो संख्यात्मक पहचानकर्ता को नाम से जोड़ती है।  5  ।   रूट डायरेक्टरी. डायरेक्टरी डाटा  और  में संग्रहीत है तथा दोनों का एट्रीब्यूट नाम 30 है।  6   बिटमैप  बिट प्रविष्टियों की एक सारिणी: प्रत्येक बिट संकेत करता है कि इसका क्लस्टर प्रयोग में (आवंटित) या खाली है (आवंटन के लिए उपलब्ध).  7   बूट  वोल्यूम बूट रिकॉर्ड. यह फ़ाइल हमेशा वोल्यूम पर पहले क्लस्टर में स्थित है। इसमें बूटस्ट्रैप कोड (  देखें) और एक  पैरामीटर ब्लॉक शामिल है जिसमें  और  की क्लस्टर संख्या और वोल्यूम सीरियल संख्या होती है। बूट आम तौर पर 8,192 बाईट्स लंबा होता है।  8     एक फ़ाइल जिसमें सभी क्लस्टर खराब क्षेत्र के रूप में चिह्नित होते हैं। यह फ़ाइल  यूटिलिटी द्वारा क्लस्टर प्रबंधन को सरल करती है, व नए खराब क्षेत्रों की खोज और बिना सन्दर्भ के क्लस्टरों की पहचान करती है। इस फ़ाइल में दो डाटा स्ट्रीम हैं, बिना खराब क्षेत्र के वोल्यूम में भी, एक अनाम स्ट्रीम में खराब क्षेत्र होते हैं- पूर्ण रूप से सही वोल्यूम के लिए यह शून्य लम्बाई है, दूसरी स्ट्रीम का नाम बैड है तथा इसमें वो सभी क्लस्टर होते हैं जो पहली स्ट्रीम में नहीं हैं।:  का प्रयोग विशेष रूप से वहां होता है जब इसके क्लस्टर के आवंटन से  द्वारा "मल्टीपल क्लस्टर संदर्भ" त्रुटी उत्पन्न नहीं होती. 9  सुरक्षित   डाटाबेस सूची तक पहुँच नियंत्रित करती है जो हर फ़ाइल के साथ एक जैसे  संग्रहित करने का खर्चा, सारे  को एक साथ विशिष्ट ढंग से संग्रहित करके कम कर देता है (इसमें दो सूचकांक : शायद सुरक्षा  इंडेक्स और : सुरक्षा डिस्क्रिप्टर हैश वास्तविक अचल तालिका युक्त  स्ट्रीम को इंडेक्स करता है).  10     यूनिकोड अपरकेस अक्षरों की एक तालिका जो 32 और डॉस नाम स्थान में केस इनसेंसिटीविटी सुनश्चित करती है।  11    एक फ़ाइल सिस्टम डायरेक्टरी जिसमें विभिन्न प्रकार के एक्सटेंशन होते हैं जैसे , , या .  12...23  विस्तार प्रविष्टियों के लिए आरक्षित.एक्सटेंशन प्रविष्टियां अतिरिक्त  रिकॉर्ड हैं जिनमें अतिरिक्त गुण होते हैं तथा जो प्राथमिक रिकॉर्ड में फिट नहीं होते हैं। फ़ाइल के पर्याप्त फ्रेगमेंटेड होने, कई स्ट्रीम के होने, लम्बे फ़ाइल नाम, जटिल सुरक्षा या अन्य दुर्लभ स्थितियों में ऐसा हो सकता है।  आम तौर पर 24   	    डिस्क कोटा की जानकारी रखती है। इसमें  तथा  दो इंडेक्स रूट होते हैं।  आम तौर पर 25  0  डिस्ट्रीब्यूटेड लिंक ट्रैकिंग की जानकारी रखती है।  नाम की इंडेक्स रूट और आबंटन तालिका रखती है।  आम तौर पर 26        रिपार्स पॉइंट डाटा रखती है (जैसे सिम्बोलिक लिंक्स).  नाम की इंडेक्स रूट और आबंटन तालिका रखती है।  27 ...  .   नियमित रूप से फ़ाइल प्रविष्टियों की शुरुआत. 

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

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

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

  रिकॉर्ड में वर्णित प्रत्येक फ़ाइल के लिए (या स्ट्रीम डिस्क्रिप्टर की नॉन-रेसिडेंट रिपोजिट्री, नीचे देखें), स्ट्रीम डिस्क्रिप्टर की पहचान (स्ट्रीम वैल्यू प्रकार, स्ट्रीम का नाम) अद्वितीय होनी चाहिए। अतिरिक्त रूप से,  में डिस्क्रिप्टर के साथ ऐसा करने में कुछ बाधाएं हैं। 
 यह एक पूर्वनिर्धारित रिक्त स्ट्रीम प्रकार है जिसका प्रयोग उस फ़ाइल की स्ट्रीम रिपोजिट्री में स्ट्रीम डिस्क्रिप्टर की सूची का अंत प्रदर्शित करने के लिए किया जाता है। इसे प्रत्येक स्ट्रीम रिपोजिट्री के अंतिम स्ट्रीम डिस्क्रिप्टर में उपस्थित होना चाहिए। (इसके बाद दूसरे संग्रहण स्थान नज़रंदाज़ कर दिए जायेंगे तथा  में रिकॉर्ड के साइज़ को या नॉन-रेसिडेंट स्ट्रीम रिपोजिट्री में क्लस्टर साइज़ को मैच करने के लिए पैडिंग बाइट्स रहेंगे).
 स्ट्रीम के कुछ प्रकारों की आवश्यकता पड़ती है तथा ये प्रत्येक  रिकॉर्ड में उपस्थित होने चाहिए सिवाए अप्रयुक्त रिकार्डों के जिन्हें स्ट्रीम द्वारा रिक्त स्ट्रीम प्रकार द्वारा पर्दर्शित किया जाता है। 
 मानक एट्रीब्यूट के केस में जो निश्चित साइज़ रिकॉर्ड की तरह संग्रहित होते हैं तथा जिनमें टाइम स्टांप तथा दूसरे सिंगल बिट एट्रीब्यूट होते हैं। (डॉस में 32 या  9598 द्वारा प्रबंधित एप्लीकेशंस के साथ सामंजस्य है) 
 कुछ स्ट्रीम प्रकारों का नाम नहीं हो सकता तथा उन्हें गुमनाम ही रहना चाहिए। 
 मानक एट्रीब्यूट के केस में, या फिर प्राथमिकता प्राप्त  "फ़ाइल नाम" प्रकार की स्ट्रीम, या "छोटा फ़ाइल नाम" प्रकार की स्ट्रीम भी उपस्थित हों.(डॉस की तरह की एप्लीकेशंस के साथ सामंजस्य के लिए).यह भी संभव है एक फ़ाइल का केवल एक छोटा फ़ाइल नाम, उस मामले में यह   की सूची में प्रथम स्थान पर होगी। 
 स्ट्रीम रिपोजिट्री में संग्रहित फ़ाइल नाम स्ट्रीम शाखाक्रम फ़ाइल सिस्टम के अनुसार फ़ाइल को एकदम उपलब्ध नहीं कराते. वास्तव में, सभी फ़ाइल नाम कम से कम एक अलग डायरेक्टरी में अपनी  प्रविष्टि, सुरक्षा डिस्क्रिप्टर और एट्रीब्यूट, जो उस फ़ाइल की  प्रविष्टी संख्या बतायेगा, के साथ एक ही वोल्यूम पर अलग से क्रमबद्ध होने चाहियें. यह एक ही वोल्यूम पर कई जगहों पर संभवतः अलग फ़ाइल नामों के साथ एक ही फ़ाइल या डायरेक्टरी के हार्ड लिंक की अनुमति देता है। 
 एक नियमित फ़ाइल की डिफाल्ट डाटा स्ट्रीम  लेकिन अनाम फ़ाइल नाम तथा समान  के साथ है किन्तु इसका नामकरण होना चाहिए। 
 इसके विपरीत डायरेक्टरी की डिफॉल्ट डाटा स्ट्रीम अलग प्रकार की है लेकिन अनाम नहीं है। इनका स्ट्रीम नाम ( 3 में "30") है जो इंडेक्सिंग प्रारूप को दर्शाता है।

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

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

 फ़ाइल सिस्टम ड्राईवर कभी कभी स्ट्रीम रिपोजिट्री में नॉन-रेसिडेंट स्ट्रीम को डालने का प्रयास करता है तथा नॉन-रेसिडेंट रिपोजिट्री में संग्रहित स्ट्रीम डिस्क्रिप्टर को  रिकॉर्ड की स्ट्रीम रिपोजिट्री में डालने का भी प्रयास करता है। यह प्रयास प्राथमिकता और प्राथमिकता के आधार पर आदेश के नियम और आकार पर निर्भर हैं।

चूंकि रेसिडेंट फाईलें क्लस्टर ("आवंटन इकाइयों") पर कब्ज़ा नहीं करतीं, इसलिए एक  वोल्यूम पर क्लस्टर से ज्यादा फ़ाइल नामों का होना संभव है। उदाहरण के लिए, एक 80  पार्टीशन (74.5) के 4 के 19,543,064 क्लस्टर हो सकते हैं। सिस्टम फाईलों (64   फ़ाइल, 2,442,888 बाइट्स की बिटमैप फ़ाइल तथा 25 फिक्स क्लस्टर के साथ) को घटाने के पश्चात् 19,526,158 क्लस्टर फाईलों तथा सूचियों के लिए खाली हैं। क्योंकि एक क्लस्टर में 4  रिकॉर्ड हैं, यह वोल्यूम सैद्धांतिक रूप से लगभग 4  19,526,158  78,104,632 रेसिडेंट फ़ाइलों को संभाल सकता है।

 सीमाएं 
 की कुछ निम्नलिखित सीमाएं हैं:

आरक्षित फ़ाइल नाम 
हालांकि फ़ाइल सिस्टम पाथ का 32,767 यूनीकोड अक्षरोंइसके अतिरिक्त, 32,767 . 255 -16  शब्द. कुछ दुर्लभअसामान्य यूनिकोड अक्षरों को ऐसे दो शब्दों की आवश्यकता है। का समर्थन करता है जिसमें प्रत्येक पाथ (डायरेक्टरी या फ़ाइल का नाम) 255 अक्षर तक का हो सकता है, कुछ नामों का प्रयोग नहीं किया जा सकता क्योंकि  अपना मेटाडाटा नियमित (छिपी हुईं तथा ज्यादातर भाग पहुँच से बाहर होते हैं) फाईलों में संग्रहित करता है। ये फ़ाइलें रूट डायरेक्टरी में हैं (और केवल डायरेक्टरी के लिए ही आरक्षित हैं). इनके नाम नाम हैं: , , , , ,. (), , , , , , तथा ;. () तथा  दोनों डायरेक्टरी हैं तथा बाकी सभी फाईलें हैं।

वोल्यूम का अधिकतम आकार (साइज़) 
सैद्धांतिक रूप से,  वोल्यूम का अधिकतम साइज़ 2641 क्लस्टर है। बहरहाल,   प्रोफेशनल में लागू किया गया  वोल्यूम का अधिकतम आकार 232-1 क्लस्टर है। उदाहरण के लिए, 64  क्लस्टर का प्रयोग कर के एक  वोल्यूम का अधिकतम साइज़ 256  - 64  है। डिफॉल्ट क्लस्टर साइज़ 4  का प्रयोग करके  वोल्यूम का अधिकतम साइज़ 16  - 4  है। (ये दोनों   1 में में दी गयी 128  की सीमा से काफी अधिक हैं।) क्योंकि मास्टर बूट रिकॉर्ड () पर पार्टीशन टेबल केवल 2  पार्टीशन साइज़ तक का ही समर्थन करता है, 2  से अधिक के  वोल्यूम के लिए डायनेमिक या  वोल्यूम का ही प्रयोग किया जाना चाहिए.

अधिकतम फ़ाइल साइज़ 
सिद्धांत : 16 - 1  (264-210या 18,446,744,073,709,550,592 बाइट्स). क्रियान्वयन: 16  - 64  (244  216  17,592,185,978,880 बाइट्स)

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

अधिकतम पाथ लम्बाई 
एक पूर्ण पाथ 32,767 वर्ण तक लम्बा हो सकता, एक भाग 255 अक्षरों तक सीमित है। सबसे खराब स्थिति में यह 128 डायरेक्टरी तक सीमित है, लेकिन व्यवहार में इस सीमा तक शायद ही कभी आता है।

तिथि सीमा 
   के रूप में ही समय की गणना करता है: 64-बिट टाइम स्टांप की रेंज 1 जनवरी, 1601 से 28 मई, 60056 तक 10 मिलियन टिक्स (107) प्रति सेकंड है (अथार्त प्रत्येक टिक में 100 नेनो सेकंड). लेकिन व्यवहार में, सिस्टम घड़ी इतनी सटीक नहीं होती और केवल सबसे बेहतर उपलब्ध सटीक समय ही रखा जाता है (विशेषतया बेहतर सिस्टम घड़ी को बिना किसी अतिरिक्त हार्डवेयर स्पोर्ट के 10 मिली सेकंड,) इसके अलावा सभी टाइम स्टाम्प्स भी सटीक नहीं हैं : मानक एट्रीब्यूट (डॉस तथा  9598 से कम्पेटिबल) में सटीकता कम है तथा आखिरी बार फ़ाइल खोलने का समय (यदि सिस्टम रजिस्ट्री सेटिंग में इसे अक्षम न किया गया हो तो) फ़ाइल सिस्टम को तत्परता से नहीं बताया जाता और बड़े अंतरों से पूर्ण संख्या तक हो जाता है।

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

 डेवलपर्स 
 डेवलपर्स में शामिल हैं:

 टॉम मिलर 
 गैरी किमुरा 
 ब्रायन एंड्रयू 
 डेविड गोएबेल

 इन्हें भी देखें 

 फ़ाइल सिस्टम की तुलना 
 फ़ाइल-11: -2 में  की तरह समानताएं है (उदाहरण के लिए . और  और . और  की तुलना करें। ) 
 , 2 के लिए बनाया गया फ़ाइल सिस्टम 
  
  (सॉफ्टवेयर)

 सन्दर्भ 

 अतिरिक्त अध्ययनपठन 

 
 
 

बाहरी कड़ियाँ

 दस्तावेज़: 
   प्रोजेक्ट से  डिस्क संरचना की गहन परिभाषा
 .- डोक्युमेंटेशन और  के लिए संसाधन 
   तकनीकी संदर्भ 
 क्रियान्वयन 
 -3- -3 एक खुला स्रोत जो , , मैक  , ,  और  के लिए  ड्राईवर लिखतापढ़ता है। 
 -- एक खुला स्रोत जो 
 तक पहुँचने तथा उसमें हेरफेर के लिए   (लिखने का समर्थन सीमित है किन्तु सरल कार्यों के लिए प्रयुक्त हो सकता है)
का समर्थन करता है तथा  कम्पेटिबल यूटिलिटी को लिखता है। (;  , , , आदि).  अकसर किये जाने वाले सवाल और कैसे करें 
 कैप्टिव - कैप्टिव - एक परत जो  सिस्टम के तहत   ड्राईवर का प्रयोग  फ़ाइल सिस्टम तक पहुँचने के लिए करता है।

श्रेणी:माइक्रोसॉफ़्ट
श्रेणी:डिस्क फ़ाइल सिस्टम
श्रेणी:विण्डोज़ डिस्क फ़ाइल सिस्टम
श्रेणी:विण्डोज़ के घटक
श्रेणी:फ़ाइल कंप्रेशन सिस्टम्स