एन टी एफ एस

NTFS NT File System Microsoft Windows NT 3.1 July 1993 0x07 (MBR) EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (GPT) B+ tree http://msdn2.microsoft.com/en-us/library/ms995846.aspx Inside Win2K NTFS, Part 1 Mark Russinovich Microsoft Developer Network 2008-04-18 https://web.archive.org/web/20080413181940/http://msdn2.microsoft.com/en-us/library/ms995846.aspx 13 अप्रैल 2008 live Bitmap $badclus 255 UTF-16 code units http://data.linux-ntfs.org/ntfsdoc.html.gz NTFS Documentation Richard Russon and Yuval Fledel 2007-07-01 https://web.archive.org/web/20060213202831/http://data.linux-ntfs.org/ntfsdoc.html.gz 13 फ़रवरी 2006 dead 4,294,967,295 (232-1) http://technet2.microsoft.com/windowsserver/en/library/8cc5891d-bf8e-4164-862d-dac5418c59481033.mspx How NTFS Works Microsoft Corporation 2008-01-27 https://www.webcitation.org/61BaJpESU?url=http://technet.microsoft.com/en-us/library/cc706993(WS.10).aspx 24 अगस्त 2011 dead 264 − 1 clusters 264 bytes (16 EiB) minus 1 KiB In Posix namespace, any UTF-16 code unit (case sensitive) except U+0000 (NUL) and / (slash). In Win32 namespace, any UTF-16 code unit (case insensitive) except U+0000 (NUL) / (slash) \ (backslash) : (colon) * (asterisk) ? (Question mark) " (quote) < (less than) > (greater than) and | (pipe) Creation, modification, POSIX change, access 1 January 1601 – 28 May 60056 (File times are 64-bit numbers counting 100-nanosecond intervals (ten million per second) since 1601, which is 58,000+ years) 100ns Yes (see Alternate data streams below) Read-only, hidden, system, archive, not content indexed, off-line, temporary, compressed ACLs Per-file, LZ77 (Windows NT 3.51 onward) Yes Per-file,DESX (Windows 2000 onward),Triple DES (Windows XP onward),AES (Windows XP Service Pack 1, Windows Server 2003 onward) Windows NT family (Windows NT 3.1 to Windows NT 4.0, Windows 2000, Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7) NTFS Windows NT, तथा इसके बाद के संस्करणों Windows 2000, Windows XP, Windows Server 2003, Windows Server 2008, Windows Vista और Windows 7 की मानक फ़ाइल प्रणाली है. Custer Helen Inside the Windows NT File System 1994 Microsoft Press 978-1-55615-660-1 registration https://archive.org/details/insidewindowsntf00cust NTFS ने Microsoft के Windows ऑपरेटिंग सिस्टम की प्राथमिक फ़ाइल प्रणाली के रूप में FAT फ़ाइल सिस्टम का स्थान ले लिया है। NTFS, FAT तथा HPFS (उच्च प्रदर्शन वाली फ़ाइल प्रणाली) से कई मायनों में बेहतर है क्योंकि यह मेटाडाटा के लिए अधिक सहायक है और इसमें उन्नत डाटा संरचनाओं का प्रयोग बेहतर प्रदर्शन, विश्वसनीयता तथा डिस्क स्पेस के उपयोग के लिए किया गया है, साथ ही साथ कुछ अतिरिक्त सुविधायें जैसे कि सुरक्षा एक्सेस कंट्रोल लिस्ट (ACL), व फ़ाइल सिस्टम जर्नलिंग भी है। इतिहास 1980 के दशक के मध्य में, Microsoft और IBM ने आने वाली पीढ़ी के लिए चित्रमय ऑपरेटिंग सिस्टम बनाने के लिए एक संयुक्त परियोजना का गठन किया। इस परियोजना के परिणामस्वरूप OS/2, बना, लेकिन Microsoft और IBM कई महत्वपूर्ण मुद्दों पर असहमत हो जाने की वजह से अलग हो गए। OS/2 IBM की एक परियोजना बना रहा। Microsoft ने Windows NT पर काम शुरू कर दिया। OS/2 फ़ाइल प्रणाली HPFS में कई महत्वपूर्ण नई सुविधायें थीं। जब Microsoft ने अपना नया ऑपरेटिंग सिस्टम बनाया, उन्होनें NTFS के लिए इन में से कई अवधारणाओं का प्रयोग किया।http://www.pcguide.com/ref/hdd/file/ntfs/over-c.html Overview and History of NTFS Kozierok Charles M. April 17, 2001 PCGuide 8 जनवरी 2010 https://web.archive.org/web/20100102061347/http://pcguide.com/ref/hdd/file/ntfs/over-c.html 2 जनवरी 2010 dead . शायद एक ही स्रोत से उत्पन्न होने के परिणामस्वरूप, HPFS और NTFS डिस्क विभाजन की पहचान के लिए एक ही कोड टाइप (07) का प्रयोग करते हैं। एक ही ID का एक साथ प्रयोग करना असामान्य है क्योंकि दर्जनों कोड उपलब्ध थे और अन्य प्रमुख फ़ाइल प्रणालियों के अपने कोड हैं। FAT के नौ से ज्यादा कोड हैं (FAT12, FAT16, FAT32, आदि के लिए अलग अलग). एल्गोरिदम, जो विभाजन प्रकार 07 में फ़ाइल प्रणाली की पहचान करती है, को अतिरिक्त जांच करनी चाहिए। यह भी स्पष्ट है कि NTFS ने अपने स्थापत्य डिजाइन का कुछ भाग VMS द्वारा प्रयुक्त की जाने वाली फ़ाइल-11 से लिया है। यह शायद ही आश्चर्य की बात है क्योंकि डेव कटलर VMS और Windows NT, दोनों पर काम कर रहे मुख्य व्यक्ति थे। संस्करण NTFS ने पांच संस्करण जारी किये हैं: NT 3.1 का v1.0, जनवरी 2008 1993 के मध्य में जारी हुआ NT 3.5 का v1.1, जनवरी 2008 1994 में जारी हुआ 3.51 NT का v1.2 (1995 के मध्य में) और NT 4 (1996 के मध्य में)(कभी कभी "NTFS 4.0" के रूप में जाना जाता है, क्योंकि OS संस्करण 4.0 है) Windows 2000 का v3.0 ("NTFS V5.0") Windows XP का v3.1 (autumn 2001;"NTFS V5.1"),Windows Server 2003(spring 2003; कई बार "NTFS V5.2" के रूप में जाना जाता है),Windows Vista(2005 के मध्य में;)(कई बार "NTFS V6.0" के नाम से जाना जाता है) तथा Windows Server 2008 V1.0 और V1.1(और इससे नए संस्करण) आपस में मेल नहीं खाते अथार्त् 3.5x NT द्वारा लिखित संस्करण NT 3.1 द्वारा तब तक नहीं पढ़ा जा सकता जब तक कि NT 3.1 को NT 3.5x सीडी द्वारा अपडेट न किया जाए, जिसमें FAT बड़े फ़ाइल नाम की सुविधा भी उपलब्ध है।http://support.microsoft.com/kb/q129102/ Recovering Windows NT After a Boot Failure on an NTFS Drive Microsoft November 1, 2006 8 जनवरी 2010 https://web.archive.org/web/20121024163220/http://support.microsoft.com/kb/q129102 24 अक्तूबर 2012 live V1.2 कम्प्रेस्ड फ़ाइलों, मुद्दों तथा ACL आधारित सुरक्षा इत्यादि के लिए सहायक है। V3.0 में डिस्क कोटा, एन्क्रिप्शन, स्पार्स फ़ाइल, रीपार्स पॉइंट्स, अपडेट क्रम संख्या (USN) व्यवस्था, $ एक्सटेंड फ़ोल्डर और उसकी फ़ाइलें और पुनर्गठित सुरक्षा डिस्क्रिप्टर्स को जोड़ा गया ताकि सारी फ़ाइलें जो सुरक्षा की एक जैसी तकनीक का प्रयोग करती हैं, एक ही डिस्क्रिप्टर का सांझा प्रयोग कर सकें. V3.1 ने अनुपयोगी MFT रिकॉर्ड संख्या के स्थान पर मास्टर फ़ाइल तालिका (MFT) की प्रविष्टियों का विस्तार किया (जो क्षतिग्रस्त MFT फाइलें ठीक करने में उपयोगी है). Windows Vista ने ट्रांसेक्शनल NTFS, NTFS प्रतीकात्मक लिंक, विभाजन (पार्टीशन) के संकुचन और स्वयं-उपचार की सुविधा को पेश कियाhttp://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/STO123_WH06.ppt Storage improvements in Windows Vista and Windows Server 2008 Microsoft Corporation 2007-09-04 PowerPoint 14-20 Loveall John 2006 https://www.webcitation.org/65RcDRYfH?url=http://download.microsoft.com/download/5/b/9/5b97017b-e28a-4bae-ba48-174cf47d23cd/STO123_WH06.ppt 14 फ़रवरी 2012 live , हालांकि ये सुविधायें फ़ाइल सिस्टम से अधिक ऑपरेटिंग सिस्टम की अतिरिक्त कार्यक्षमता से सम्बंधित हैं। विशेषताएँ NTFS V3.0 अपने पूर्ववर्तियों के अपेक्षाकृत कई नई सुविधाओं से लैस है:स्पार्स फ़ाइल सुविधा, डिस्क कोटा का उपयोग, रीपार्स पॉइंट, वितरित लिंक ट्रैकिंग और फ़ाइल स्तर एन्क्रिप्शन जिसे एनक्रिप्टिंग फ़ाइल सिस्टम (EFS) के नाम से भी जाना जाता है। USN जर्नल USN जर्नल सिस्टम प्रबंधन का एक feature है जो सभी फ़ाइलों, स्ट्रीम तथा डायरेक्टरी को रिकॉर्ड करने के साथ उनकी विभिन्न विशेषताओं और सुरक्षा सेटिंग्स को रिकॉर्ड करता है। यह NTFS की एक महत्वपूर्ण कार्यक्षमता है जो (एक विशेषता जो FAT/FAT32 प्रदान नहीं करते) यह सुनिश्चित करने के लिए है कि इसका आंतरिक जटिल डाटा (खासकर वोल्यूम आवंटन बिटमैप, या डाटा स्थानांतरित करने के लिए डिफ्रेगमेन्टेशन API, MFT रिकॉर्ड में संशोधन जैसे कि MFT रिकॉर्ड में संग्रहित कुछ वेरिएबल व एट्रीब्यूट सूची, या शेयर किए गए सुरक्षा डिस्क्रिप्टर्स में कुछ अपडेट, या बूट सेक्टर व इसकी प्रतिलिपि फ़ाइल जहाँ वोल्यूम पर USN की आखिरी गतिविधि संग्रहित है) तथा सूची (डायरेक्टरी तथा सुरक्षा डिस्क्रिप्टर्स के लिए) सिस्टम के क्रैश (दुर्घटनाग्रस्त) होने की स्थिति में यथावत बने रहेंगे तथा वोल्यूम को दोबारा ठीक करने के दौरान इन महत्त्वपूर्ण डाटा संरचनाओं को फिर से उपलब्ध कराएंगे. Windows के बाद के संस्करणों में, USN जर्नल ने तब से NTFS फ़ाइल सिस्टम के अन्य क्रियान्वन में प्रयुक्त भागों में इस तरह की खोज का विस्तार करने की चेष्टा की है जैसे कि सिस्टम फ़ाइल की कॉपी-ऑन-राइट सीमेंटिक्स के साथ VSS शेडो प्रतिलिपि, या ट्रांसेक्शनल NTFS और वितरित फ़ाइल प्रणाली का क्रियान्वन (नीचे देखें). हार्ड लिंक और लघु फ़ाइल नाम मूल रूप से Windows NTMS Windows NT Workstation 4.0 रिसोर्स गाइड, "POSIX कम्पेटिबिलिटी" https://web.archive.org/web/20080501042054/http://www.microsoft.com/technet/archive/ntwrkstn/reskit/poscomp.mspx?mfr=true 1 मई 2008 में POSIX उपतंत्र में शामिल होने वाले हार्ड लिंक डायरेक्टरी जंक्शन के समान हैं, लेकिन डायरेक्टरी के बजाए फ़ाइलों के लिए प्रयुक्त होते हैं। हार्ड लिंक केवल उसी वोल्यूम की फ़ाइलों में लागू हो सकते हैं क्योंकि फ़ाइल के MFT रिकार्ड में अतिरिक्त फ़ाइल नाम का रिकॉर्ड जुड़ा हुआ है। लघु (8.3) फ़ाइल नाम भी अतिरिक्त फ़ाइल नाम रिकॉर्ड की तरह क्रियान्वित होते हैं जिनकी अलग से डायरेक्टरी प्रविष्टियाँ नहीं हैं। वैकल्पिक डाटा स्ट्रीम (ADS) वैकल्पिक डाटा स्ट्रीम एक से अधिक डाटा स्ट्रीम को एक फ़ाइल नाम के साथ, फ़ाइल नाम प्रारूप-"फ़ाइल नाम:स्ट्रीमनाम"(उदहारण के लिए: "text.txt:extrastream") का प्रयोग कर के जोड़ती है। वैकल्पिक विषय Windows Explorer में सूचीबद्ध नहीं हैं और उनका साइज़ फ़ाइल के साइज़ में शामिल नहीं है। जब एक फ़ाइल जो ईमेल अथवा वेबसाइट से अपलोड करके नेटवर्क शेयर या FAT द्वारा फॉर्मेट USB ड्राइव में कॉपी की जाती है तो उस फ़ाइल की केवल मुख्य स्ट्रीम ही संरक्षित होती है। परिणामस्वरुप, महत्वपूर्ण डाटा के लिए वैकल्पिक स्ट्रीम का प्रयोग समस्या पैदा कर सकता है। मैलवेयर वैकल्पिक डाटा स्ट्रीम का इस्तेमाल अपने कोड को छिपाने के लिए करते हैं;मालवेयर अन्य डाटा स्ट्रीम का प्रयोग करते हैं? https://web.archive.org/web/20080723180729/https://www.auscert.org.au/render.html?it=7967 23 जुलाई 2008 , AusCERT Web Log, 21 अगस्त 2007 कुछ मैलवेयर स्कैनर और अन्य विशेष उपकरण अब वैकल्पिक स्ट्रीम में डाटा की जाँच करते हैं। बाहरी साइटों से डाउनलोड की गयी फ़ाइलों को चिन्हित करने के लिए बहुत छोटे ADS Internet Explorer में (और अब अन्य ब्रॉउजर में भी) जोड़े जाते हैं: उन्हें स्थानीय रूप से चलाना असुरक्षित हो सकता है और स्थानीय सिस्टम को उन्हें खोलने से पहले यूज़र से पुष्टि की आवश्यकता होगी। जब यूज़र यह इंगित करता है उसे कन्फर्मेशन डायलॉग की और आवश्यकता नहीं है, तो डाउनलोड की गयी फ़ाइलों के लिए MFT प्रविष्टि में इस ADS को हटा दिया जाता है। कुछ मीडिया के दिग्गजों ने भी मीडिया फ़ाइलों की प्रभावी डाटा सामग्री को संशोधित किये बगैर, संग्रह को व्यवस्थित करने के लिए, कस्टम मेटाडाटा का मीडिया फ़ाइलों में संग्रहण के लिए ADS का प्रयोग किया है (मीडिया फ़ाइल प्रारूप द्वारा समर्थित एम्बेडेड टैग जैसे MPEG और OGG कंटेनर की सहायता से). इन मेटाडाटा को Windows Explorer में अतिरिक्त जानकारी कॉलम के रूप में एक पंजीकृत Windows Shell एक्सटेंशन की सहायता से दिखाया जा सकता है, जो उन्हें उन्हें पार्स कर सकते हैं। लेकिन ज्यादातर मीडिया दिग्गज इन सूचनाओं के संग्रहण के लिए ADS की बजाए अपने अलग डाटाबेस का प्रयोग करते हैं (चूंकि ADS अलग अलग यूज़र सुरक्षा सैटिंग के अभाव में इन फ़ाइलों के सभी यूज़र्स को दिखाई देते हैं और उनके मूल्य यूज़र की वरीयता के अनुसार परिभाषित होते हैं।) स्पार्स फ़ाइलें स्पार्स फ़ाइलें ऐसी फ़ाइलें हैं जिनमें स्पार्स डाटा सेट होता है तथा डाटा ज्यादातर शून्य से भरे होते हैं। डाटाबेस प्रोग्राम कभी कभी स्पार्स फ़ाइलों का उपयोग करते हैं।स्पार्स फ़ाइल त्रुटियाँ: 1450 या 665 फ़ाइल विखंडन के कारण : सुधार और कार्य https://web.archive.org/web/20100516122013/http://blogs.msdn.com/psssql/archive/2009/03/04/sparse-file-errors-1450-or-665-due-to-file-fragmentation-fixes-and-workarounds.aspx 16 मई 2010 , Microsoft ग्राहक सेवा और सहायता (CSS) SQL सर्वर इंजीनियर्स ब्लॉग, 4 मार्च 2009 इस कारण, Microsoft ने स्पार्स फ़ाइलों के कुशल संग्रहण के लिए एक प्रोग्राम को खाली (ज़ीरो) डाटा क्षेत्रों को निर्दिष्ट करने की अनुमति दी है। एक प्रोग्राम स्पार्स फ़ाइल को सामान्य तरीके से पढ़ता है तथा फ़ाइल सिस्टम यह गणना करता है कि फ़ाइल ऑफसेट पर क्या डाटा वापिस आना चाहिए। कंप्रेस फ़ाइलों के साथ, कोटा सीमा के निर्धारण के समय स्पार्स फ़ाइलों के वास्तविक साइज़ का ध्यान नहीं रखा जाता.http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/sparse_files.asp Sparse Files MSDN Platform SDK: File Systems 2005-05-22 https://web.archive.org/web/20191018203849/https://msdn.microsoft.com/library?url=%2Flibrary%2Fen-us%2Ffileio%2Ffs%2Fsparse_files.asp 18 अक्तूबर 2019 livehttp://msdn2.microsoft.com/en-us/library/aa365565.aspx Sparse FIles and Disk Quotas Win32 and COM Development: File Systems 2007-12-05 https://web.archive.org/web/20080224024620/http://msdn2.microsoft.com/en-us/library/aa365565.aspx 24 फ़रवरी 2008 live फ़ाइल कंप्रेशन NTFS LZ77 एल्गोरिथ्म के एक संस्करण का प्रयोग कर के फ़ाइलों को कंप्रेस (लोकप्रिय ज़िप फ़ाइल प्रारूप में भी प्रयुक्त होता है) कर सकता है।http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/file_compression_and_decompression.asp File Compression and Decompression MSDN Platform SDK: File Systems 2005-08-18 https://web.archive.org/web/20191018203854/https://msdn.microsoft.com/library?url=%2Flibrary%2Fen-us%2Ffileio%2Ffs%2Ffile_compression_and_decompression.asp 18 अक्तूबर 2019 live हालांकि कंप्रेस फ़ाइलों को पढ़ने-लिखने की पहुँच पारदर्शी है, Microsoft सर्वर सिस्टम तथा/या रो़मिंग प्रोफाइल के साथ नेटवर्क शेयर पर कंप्रेशन की अनुशंसा नहीं करता क्योंकि यह प्रोसेसर पर भारी बोझ डालता है।"Windows में NTFS कंप्रेशन के लिए सर्वोत्तम अभ्यास." https://web.archive.org/web/20131113184821/http://support.microsoft.com/default.aspx?scid=kb;en-us;Q251186 13 नवंबर 2013 Microsoft ज्ञान आधार 18-08-2005 को लिया गया। सीमित हार्ड डिस्क स्थान के साथ एक सिंगल यूज़र सिस्टम शायद NTFS कंप्रेशन का सफलतापूर्वक प्रयोग करेगा.December 2007 एक कंप्यूटर में धीमी कड़ी CPU नहीं बल्कि हार्ड ड्राइव की गति है, इसलिए NTFS कंप्रेशन स्थान तथा (अक्सर) गति के रूप में सीमित, बेहतर प्रयोग के लिए धीमी गति से संग्रहण करता है।http://www.windowsitlibrary.com/Content/435/07/8.html Optimizing Disks Sean Daily जनवरी 1998 IDG books 2007-12-17 https://web.archive.org/web/20071217083624/http://www.windowsitlibrary.com/Content/435/07/8.html 17 दिसंबर 2007 dead NTFS कंप्रेशन स्पार्स फ़ाइलों का भी स्थान ले सकता है जब एक प्रोग्राम (उदाहरण - एक Download Manager) स्पार्स फ़ाइलों की सामग्री के बिना फ़ाइलें नहीं बना सकता. वोल्यूम शैडो की प्रतिलिपि वोल्यूम शैडो की प्रतिलिपि सेवा (VSS) NTFS वोल्यूम पर फ़ाइलों तथा फोल्डर के ऐतिहासिक संस्करणों को कॉपी कर के पुराने, नये ओवरराइट डाटा की शैडो कॉपी बनाती है (कॉपी-ऑन-राइट) . जब यूज़र पहले के संस्करण को वापस पाना चाहता है तो नयी फ़ाइलों पर पुराना डाटा वापिस आ जाता है। यह बैकअप प्रोग्राम को फ़ाइल सिस्टम द्वारा प्रयुक्त की जा रहीं फ़ाइलों के संग्रहण की भी अनुमति देता है। भारी लोड वाले सिस्टम पर, Microsoft एक अलग डिस्क पर शैडो कॉपी रखने की अनुशंसा करता है।http://technet.microsoft.com/en-us/library/cc728305.aspx Designing a Shadow Copy Strategy Microsoft TechNet 2008-01-15 https://web.archive.org/web/20090405181951/http://technet.microsoft.com/en-us/library/cc728305.aspx 5 अप्रैल 2009 live सिस्टम के लगातार क्रैश होने के मामलों में, VSS लोकल ट्रांसेक्शन को चिन्हित करने के लिए USN जर्नल का प्रयोग करता है और यह सुनिश्चित करता है कि NTFS वोल्यूम दोबारा डालने तथा सिस्टम को दोबारा चालू करने के पश्चात् फाइलों के प्रतिबद्ध परिवर्तन प्रभावशाली ढंग से दोबारा प्राप्त हो जाएँ अथवा संशोधित फ़ाइल बंद होने के कारण नए संस्करण के रिकॉर्ड न होने की स्थिति में सुरक्षित ढंग से पुराना संस्करण लोड हो जाए. हालांकि, ये VSS शैडो ट्रांसेक्शन कोर्डिनेटर (नीचे देखें) के बिना कई सारी फ़ाइलों या वोल्यूम पर समन्वय नहीं कर रहे हैं। इन्हें सिर्फ यह सुनिश्चित करने के लिए प्रयोग किया जा सकता है कि बैकअप के दौरान पुराने संस्करण उपलब्ध रहे ताकि उन बैकअप के द्वारा सिस्टम की लगातार छवियों को प्राप्त किया जा सके। ट्रांसेक्शनल NTFS Windows Vista में, प्रोग्राम के द्वारा फ़ाइलों में होने वाले सामूहिक परिवर्तनों को ट्रांसेक्शन में परिवर्तित करने के लिए ट्रांसेक्शनल NTFS का प्रयोग कर सकते हैं। ट्रांसेक्शन सभी परिवर्तनों के होने या न होने की गारंटी देता है तथा यह भी गारंटी देता है कि बिना प्रतिबद्धता के ट्रांसेक्शन के बाहर कोई परिवर्तन नहीं होगा। http://msdn2.microsoft.com/en-us/library/aa363764.aspx Transactional NTFS MSDN 2007-02-02 https://web.archive.org/web/20081011213523/http://msdn2.microsoft.com/en-us/library/aa363764.aspx 11 अक्तूबर 2008 live यह वोल्यूम शैडो कॉपी (अथार्त् कॉपी-ऑन-राइट) में प्रयुक्त होने वाली तकनीकें प्रयुक्त करता है ताकि ओवरराइट किया गया डाटा सुरक्षित ढंग से वापिस लाया जा सके, तथा बिना प्रतिबद्धता वाली अथवा प्रतिबद्ध हो चुकी किन्तु पूरी तरह क्रियान्वित न होने वाली ट्रांसेक्शन को USF जर्नल लॉग चिन्हित कर ले (क्रियान्वन के दौरान किसी प्रतिभागी द्वारा सिस्टम क्रैश होने की स्थिति में). हालांकि, ट्रांसेक्शनल में सक्षम फ़ाइल सिस्टम में, जब तक ट्रांसेक्शन प्रतिबद्ध नहीं है, इसे किसी भी तरह के पार्टीशन के लिए अस्थाई रूप से प्रयोग किया जा सकता है, बजाए सिस्टम फ़ाइलों के जो कॉपी-ऑन-राइट सीमेंटिक्स के द्वारा स्थाई रूप से चिन्हित हैं और अपनी स्थानीय ट्रांसेक्शन के द्वारा पूर्ण रूप से संशोधित हैं। प्रभावशाली ढंग से डाटा वापिस लेने तथा प्रतियोगियों द्वारा फ़ाइल सिस्टम में संभावित विखंडन से बचने के लिए कॉपी-ऑन-राइट तकनीक में संशोधन किया गया है। पुराना डाटा तुंरत ओवरराइट नहीं होता अपितु अपनी जगह पड़ा रहता है (खासकर जब किसी के द्वारा अपनी ट्रांसेक्शन को लगातार पढ़ने के लिए लॉक किया जाता है), इस स्थिति में केवल नया अप्रतिबद्ध डाटा ही अस्थायी शैडो में रखा जाता है (पुराने डाटा को कॉपी-ऑन-राइट करने के बजाए) तथा अंततः लेखक द्वारा ट्रांसेक्शन को पूरा करने के पश्चात् सामान्य VSS कॉपी-ऑन-राइट का प्रयोग किया जाता है। इसके अतिरिक्त, यह जरूरी नहीं है कि नये डाटा के लिए अस्थायी शैडो, जो केवल अप्रतिबद्ध डाटा वाली प्रतिभागी प्रक्रियाओं द्वारा देखी जा सकती है तुंरत डिस्क पर लिखी जाए अपितु मेमोरी में रखी जा सकती है और जरूरत पड़ने पर बदली जा सकती है। NTFS ट्रांसेक्शन केवल स्थानीय NTFS वोल्यूम तक ही सीमित नहीं है बल्कि इसमें दूसरे स्थान के ट्रांसेक्शनल डाटा व प्रक्रियाएं भी शामिल हैं जैसे कि दूसरे वोल्यूम में संग्रहित डाटा, स्थानीय रजिस्ट्री, SQL डाटाबेस, वर्तमान स्थिति में सिस्टम सर्विस या रिमोट सर्विस. ये ट्रांसेक्शन किसी विशिष्ट सेवा का प्रयोग कर रहे सभी प्रतिभागियों द्वारा नेटवर्क के माध्यम से समन्वित होती है जिसका नाम डिस्ट्रीब्यूटेड ट्रांसेक्शन कोर्डिनेटर (DTC) है जो यह सुनिश्चित करती है सभी प्रतिभागी एक जैसी स्थिति में काम करेंगे, तथा किसी प्रतिभागी द्वारा पुष्टि किये जाने पर बदलावों को सब तक पहुँचाया जायेगा (ताकि दूसरे प्रतिभागी अपनी पुराने डाटा वाली स्थानीय मेमोरी को रद्द कर सकें या अप्रतिबद्ध बदलावों को पुरानी स्थिति में ले आयें। ) उदाहरण के लिए ट्रांसेक्शनल NTFS नेटवर्क में वितरित फ़ाइल सिस्टम की अनुमति देता है जिसमें उनकी स्थानीय ऑनलाइन या ऑफलाइन मेमोरी भी शामिल है। फ़ाइल को कूटबद्ध करने का सिस्टम (EFS) EFS NTFS वोल्यूम पर किसी भी फ़ाइल अथवा फोल्डर को शक्तिशाली तथा पारदर्शी ढंग से कूटबद्ध करता है।http://technet.microsoft.com/en-us/magazine/2007.02.securitywatch.aspx Security Watch Deploying EFS: Part 1 John Morello Technet Magazine 2007 February 2009-01-25 https://web.archive.org/web/20100108161037/http://technet.microsoft.com/en-us/magazine/2007.02.securitywatch.aspx 8 जनवरी 2010 live EFS, EFS सेवा, Microsoft के CryptoAPI और EFS File System Run- Time Library (FSRTL) के साथ इकठ्ठे काम करता है। EFS एक फ़ाइल को सीमेट्रिक कुंजी के साथ कूटबद्ध करता है (फ़ाइल एनक्रिप्शन की या FEK के नाम से भी जानी जाती है) जो इसलिए प्रयुक्त की जाती है जो असीमेट्रिक कुंजी के बजाए बड़ी मात्रा में डाटा को कूटबद्ध अथवा डिकोड करने में कम समय लेती है। सीमेट्रिक कुंजी, जिसका प्रयोग फ़ाइल को कूटबद्ध करने में किया गया था, को एक यूज़र, जिसने फ़ाइल को कूटबद्ध किया था, द्वारा पब्लिक कुंजी की सहायता से कूटबद्ध किया जाता है और इस कूटबद्ध डाटा को कूटबद्ध फ़ाइल की वैकल्पिक डाटा स्ट्रीम में रखा जाता है। फ़ाइल को डिकोड करने के लिए, फ़ाइल सिस्टम यूज़र की निजी कुंजी का उपयोग असीमेट्रिक कुंजी को डिकोड करने के लिए करता है जो फ़ाइल हैडर में संग्रहित होती है। इसके पश्चात् यह फ़ाइल को डिकोड करने के लिए सीमेट्रिक कुंजी का प्रयोग करता है। क्योंकि यह फ़ाइल सिस्टम के स्तर पर किया जाता है, यह यूज़र के लिए पारदर्शी है।EFS कैसे काम करता है, https://web.archive.org/web/20070427062206/http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsck_efs_duwf.mspx 27 अप्रैल 2007 Microsoft Windows 2000 संसाधन किट इसके अलावा, यूज़र द्वारा अपनी कुंजी को खोने की स्थिति में, EFS सिस्टम में अतिरिक्त डिकोड कुंजियों की व्यवस्था की गयी है ताकि जरूरत पड़ने पर रिकवरी एजेंट फ़ाइल का प्रयोग कर सकें. NTFS द्वारा प्रदान की गयी कूटबद्ध तथा संपीड़न सुविधाएं परस्पर अनोखी हैं। NTFS का प्रयोग किसी एक अथवा दूसरे के लिए अलग उपकरण के तौर पर किया जा सकता है। EFS की सुविधा Windows के बेसिक, होम तथा मीडिया सेंटर संस्करण में उपलब्ध नहीं है तथा Windows के प्रोफेशनल, अल्टीमेट तथा सर्वर संस्करण के लोड करने के पश्चात या Windows डोमेन में इंटरप्राईज़ द्वारा प्रदत्त टूल का प्रयोग करके एक्टिवेट की जानी चाहिए। कोटा डिस्क कोटा की शुरुआत NTFS v3 से की गयी थी। ये कंप्यूटर के एडमिनिस्ट्रेटर को Windows का संस्करण चलाने की अनुमति देता है जिस से NTFS की सहायता से डिस्क स्थान बनाया जा सकता है जिसका उपयोग यूज़र बाद में कर सकता है। यह एडमिनिस्ट्रेटर को यह भी जानने में मदद करता है कि प्रत्येक यूज़र डिस्क के कितने स्थान का उपयोग कर रहा है। एडमिनिस्ट्रेटर यूज़र द्वारा प्रयोग किये जाने वाले डिस्क स्थान का एक निश्चित स्तर निर्धारित कर सकता है जिसके पश्चात् एक चेतावनी मिलती है और स्थान की सर्वोच्च स्थिति तक पहुँचने के पश्चात् यूज़र को मना किया जा सकता है। डिस्क कोटा NTFS के पारदर्शी फ़ाइल संपीड़न के सक्षम होने के बावज़ूद इसे गतिविधि में शामिल नहीं करता. जिन प्रोग्राम को चलाने के लिए खाली डिस्क स्थान की आवश्कता पड़ती है वे यूज़र को निर्धारित किया गया कोटा देख सकते हैं। डिस्क कोटा की सुविधा Windows के बेसिक, होम तथा मीडिया सेंटर संस्करण में उपलब्ध नहीं है तथा Windows के प्रोफेशनल, अल्टीमेट तथा सर्वर संस्करण के लोड करने के पश्चात या Windows डोमेन में इंटरप्राईज़ द्वारा प्रदत्त टूल का प्रयोग करके एक्टिवेट की जानी चाहिए। रिपार्स पॉइंट यह सुविधा NTFS v3 में पेश की गयी थी। इनका उपयोग एक फ़ाइल या डायरेक्टरी की यूज़र स्पेस विशेषता में रिपार्स टैग को जोड़ कर किया जाता है। जब ऑब्जेक्ट मैनेजर (देखें - Windows NT लाइन एग्जीक्यूटिव) फ़ाइल सिस्टम नाम लुकअप को पार्स करता है और रिपार्स एट्रीब्यूट का सामना करता है, तो यह जानता है कि नाम लुकअप को रिपार्स करना है तथा यूज़र द्वारा नियंत्रित रिपार्स डाटा को Windows 2000 में लोड किये गये प्रत्येक फ़ाइल सिस्टम फिल्टर ड्राईवर को भेजना है। प्रत्येक फिल्टर ड्राईवर रिपार्स डाटा की जाँच यह देखने के लिए करता है कि यह उस रिपार्स पॉइंट से जुड़ा हुआ है कि नहीं और ऐसा होने की स्थिति में यह फ़ाइल सिस्टम कॉल को अवरुद्ध करता है तथा अपनी विशेष कार्यशीलता को क्रियान्वित करता है। रिपार्स पॉइंट का प्रयोग वोल्यूम माउंट पॉइंट, डायरेक्टरी जंक्शन, संग्रहण प्रबंधन, संरचनात्मक संग्रहण व सिम्बोलिक लिंक को लागू करने में किया जाता है। वोल्यूम माउंट पॉइंट Unix माउंट पॉइंट की तरह है, जहां एक फ़ाइल सिस्टम का मूल एक डायरेक्टरी से जुड़ा हुआ है। NTFS में, यह एक अतिरिक्त फ़ाइल सिस्टम को, बिना किसी ड्राइव अक्षर (जैसे c: या d:) के, बढ़ने की अनुमति देता है। एक बार वोल्यूम के दूसरे वोल्यूम की मौजूदा डायरेक्टरी के ऊपर कॉपी होने की स्थिति में उस डायरेक्टरी की पिछली सामग्री अदृश्य हो जाती है माउंट किये गये वोल्यूम की रूट डायरेक्टरी से बदल जाती है। माउंट होने वाला वोल्यूम के पास फिर भी स्वयं द्वारा घोषित ड्राइव अक्षर हो सकता है। फ़ाइल सिस्टम कभी भी वोल्यूम को एक दूसरे के ऊपर माउंट करने की अनुमति नहीं देते. वोल्यूम माउंट पॉइंट को लगातार (सिस्टम रिबूट के बाद स्वत: रिमाउंट हो जाता है) या नहीं बनाया जा सकता है। माउंट किये गये वोल्यूम NTFS के बजाए दूसरे फ़ाइल सिस्टम का प्रयोग कर सकते हैं, वे संभवतः अपनी खुद की सुरक्षा व्यवस्था के साथ रिमोट द्वारा शेयर की गयी डायरेक्टरी हो सकते हैं तथा रिमोट फ़ाइल सिस्टम नीति के अनुसार नियंत्रण अधिकार की रीमैपिंग कर सकते हैं। डायरेक्टरी जंक्शन वोल्यूम माउंट पॉइंट की तरह है, हालाँकि डायरेक्टरी जंक्शन फ़ाइल सिस्टम में दूसरे वोल्यूम के बजाए दूसरी डायरेक्टरी का सन्दर्भ देते हैं। उदाहरण के लिए, डायरेक्टरी C:\exampledir, डायरेक्टरी जंक्शन एट्रीब्यूट जिसका लिंक D:\linkeddir के साथ है, यूज़र मोड ऍप्लिकेशन द्वारा प्रयोग किये जाने पर अपने आप डायरेक्टरी D:\linkeddir को संदर्भित करेगा। यह क्रियान्वन धारणात्मक रूप से Unix की डायरेक्टरी लिंक के समान है, सिवाय इसके कि NTFS में लक्ष्य हमेशा दूसरी डायरेक्टरी होगी (Unix फ़ाइल सिस्टम सिम्बोलिक लिंक के लक्ष्य को किसी भी प्रकार की फ़ाइल बनने की अनुमति देता है) तथा हार्ड लिंक के लक्षण होगे (अर्थात् बनने के तुंरत बाद वे दोबारा सुलझने की स्थिति में होने चाहियें). डायरेक्टरी लगातार जुड़ती है (जिसे MKLINK /J junctionName targetDirectory निर्देश के साथ बनाया जा सकता है तथा कन्सोल प्रोम्प्ट से RMDIR junctionName निर्देश द्वारा हटाया जा सकता है) तथा सर्वर पर हल होती है क्योंकि वे स्थानीय सिस्टम या डोमेन, जिस पर पेरेंट वोल्यूम माउंट है, के समान सुरक्षा क्षेत्र को बांटते हैं तथा लक्ष्य डायरेक्टरी की सामग्री के अनुसार अपनी सामग्री की सुरक्षा व्यवस्था करते हैं, हालाँकि जंक्शन की अलग सुरक्षा व्यवस्था हो सकती है। एक डायरेक्टरी जंक्शन का लिंक हटने पर लक्ष्य डायरेक्टरी की फ़ाइलें नष्ट नहीं होतीं. नोट: Windows के पिछले संस्करणों के साथ कम्पेटेबिलिटी (संगतता) के लिए Windows Vista पर कुछ डायरेक्टरी जंक्शन डिफ़ॉल्ट रूप से स्थापित किये गये हैं, जैसे सिस्टम ड्राइव की मूल डायरेक्टरी में Documents and Settings, जो समान वोल्यूम की मूल डायरेक्टरी में Users की फिज़िकल डायरेक्टरी से जुड़ते हैं। लेकिन वे डिफ़ॉल्ट रूप से छिपे हैं और उनकी सुरक्षा व्यवस्था इस ढंग से की गयी है कि शैल पर Windows Explorer उन्हें, स्थानीय आंतरिक सिस्टम यूज़र या स्थानीय एडमिनिसट्रेटर समूह को छोड़कर, इन्हें खोलने से मना कर देगा (दोनों यूज़र अकाउंट सिस्टम सॉफ्टवेर इंस्टालर द्वारा प्रयुक्त किये जाते हैं।) ये अतिरिक्त सुरक्षा प्रतिबंध शायद इसलिए बनाये गए हैं ताकि यूज़र गलती से जुड़ी हुयी डायरेक्टरी में इनकी डुप्लीकेट फाईलों को ढूंढ कर नष्ट न कर दे, क्योंकि डायरेक्टरी जंक्शन की प्रक्रिया हार्ड लिंक्स की तरह नहीं है- लक्ष्य सामग्री के लिए रेफ्रेन्स गिनती नहीं की जाती और यहाँ तक कि स्वयं रेफर किये गए कंटेनर द्वारा भी नहीं की जाती. डायरेक्टरी जंक्शन सॉफ्ट लिंक होते हैं (लक्ष्य डायरेक्टरी को हटाने के बाद भी वे बने रहेंगे), तथा सिम्बोलिक लिंक्स के सीमित रूप में कार्य करते हैं (लक्ष्य पर अतिरिक्त प्रतिबंध के साथ), लेकिन यह एक अनुकूलित संस्करण है जो रिपार्स पॉइंट की प्रक्रिया को क्रियान्वन के दौरान तेज़ करता है तथा नये NTFS सिम्बोलिक लिंक्स से कम खर्चे पर चलता है तथा इसे सर्वर पर हल किया जा सकता है। (जब वे रिमोट द्वारा शेयर की गयी डायरेक्टरी में मिलते हैं) सिम्बोलिक (प्रतीकात्मक) लिंक सिम्बोलिक लिंक्स(या सॉफ्ट लिंक) Windows Vista में शुरू किए गए थे। सिम्बोलिक लिंक्स ग्राहक छोर पर हल किये जाते हैं। इसलिए, जब एक सिम्बोलिक लिंक सांझा किया जाता है, तो लक्ष्य ग्राहक के पहुँच प्रतिबंधों के अधीन है, न कि सर्वर के. सिम्बोलिक लिंक्स फाईलों (MKLINK symLink targetFilename के साथ बनाया गया) अथवा डायरेक्टरी (MKLINK /D symLinkD targetDirectory के साथ बनाया गया) में बनाये जा सकते हैं, किन्तु लिंक का अर्थ निर्मित लिंक के साथ उपलब्ध कराया जाना चाहिए। लेकिन सिम्बोलिक लिंक बनने के दौरान लक्ष्य का अस्तित्व में होना या उपलब्ध होना आवश्यक नहीं है। जब सिम्बोलिक लिंक की जांच होगी तथा लक्ष्य को उपलब्धता के लिए जांचा जाएगा, NTFS भी जांच करेगा कि इसका प्रकार सही है या नहीं (फ़ाइल अथवा डायरेक्टरी का). लक्ष्य का प्रकार गलत होने की स्थिति में यह नहीं-मिला (Not-Found) की त्रुटी दर्शायेगा. ये रिमोट होस्ट पर शेयर की गयी डायरेक्टरी अथवा उस डायरेक्टरी की फाईलों या सब डायरेक्टरी की ओर संकेत कर सकते हैं। बूट करने पर उनका लक्ष्य एकदम से निर्धारित नहीं होता बल्कि OpenFile() या CreateFile()API के साथ खोलने पर अस्थायी रूप से उपलब्ध होता है। NTFS वोल्यूम पर उनकी परिभाषा निरंतर है जहां वे उत्पन्न होते हैं। (सभी प्रकार के सिम्बोलिक लिंक्स फाईलों की तरह कमांड लाइन प्रोम्प्ट या बैच से DEL symLink का उपयोग कर के हटाए जा सकते हैं). Computer shortcut एकल चरण संग्रहण (SIS) बहुत सी डायरेक्ट्रियों में विभिन्न किन्तु एक जैसी फाईलें हो सकती हैं, इन फ़ाइलों में से कुछ में समान सामग्री हो सकती हैं। एकल चरण संग्रहण समान फाईलों का एक फ़ाइल में विलय करने और विलय फ़ाइल संदर्भ बनाने की अनुमति देता है। SIS में एक फ़ाइल सिस्टम फिल्टर होता है जो फाईलों की प्रतिलिपियों, संशोधनों तथा विलयों का प्रबंधन करता है तथा एक यूज़र स्पेस सेवा (या ग्रोवेलेर) जो उन फाईलों को ढूंढती है जो समान हैं, तथा जिनका विलय करने की आवश्यकता है। SIS मुख्य रूप से रिमोट इंस्टालेशन सर्वर के लिए डिजाईन किया गया था क्योंकि इनकी बहुत अधिक इंस्टालेशन छवियाँ होती हैं जिनमें कई एक जैसी फाईलें हो सकती हैं। SIS इन्हें इकट्ठा करता है किन्तु हार्ड लिंक के उदाहरण के विपरीत हर फ़ाइल अलग अलग रहती है, फ़ाइल की किसी एक प्रति में परिवर्तन करने से बाकी फाईलों पर परिवर्तन का असर नहीं होता। यह कॉपी-ऑन-राइट तकनीक के समान है जिसमें एक कॉपी के संशोधित होने तक मेमोरी पूरी तरह से कॉपी नहीं होती.http://research.microsoft.com/sn/Farsite/WSS2000.pdf PDF Single Instance Storage in Windows 2000 Microsoft Research and Balder Technology Group 8 जनवरी 2010 https://web.archive.org/web/20081029163043/http://research.microsoft.com/sn/Farsite/WSS2000.pdf 29 अक्तूबर 2008 live शाखाकृत संग्रहण प्रबंधन (HSM) शाखाकृत संग्रहण प्रबंधन कम खर्चीली संग्रहण प्रणाली में उन फ़ाइलों को स्थानांतरित करने का एक साधन है जो कुछ अवधि से प्रयुक्त नहीं हो रही हैं। जब फ़ाइल को अगली बार खोला जाता है तो फ़ाइल का रिपार्स पॉइंट इसकी आवश्यकता निर्धारित करता है और इसे संग्रहण से प्राप्त करता है। नेटिव संरचित संग्रहण (NSS) NSS एक ActiveX दस्तावेज़ संग्रहण तकनीक थी जिसे Microsoft द्वारा रोक दिया गया था। यह ActiveX दस्तावेज़ों को एक ही मल्टी स्ट्रीम प्रारूप में संग्रहण की अनुमति देता था जिसे ActiveX आंतरिक रूप से उपयोग करता है। एक NSS फ़ाइल सिस्टम फिल्टर को लोड किया गया और इसका प्रयोग मल्टीपल स्ट्रीम को पारदर्शी ढंग से प्रोग्राम को भेजने के लिए किया गया तथा जब फ़ाइल को non-NTFS फॉरमेटेड डिस्क वोल्यूम पर भेजा गया तो इसने सिंगल स्ट्रीम के साथ मल्टीपल स्ट्रीम को भी स्थानांतरित कर दिया। ज़न सेविल, "मूल संरचनात्मक संग्रहण क्या है? https://web.archive.org/web/20070927212324/http://www.windowsitpro.com/Article/ArticleID/13785/13785.html 27 सितंबर 2007 " मिल कर कार्य करने की क्षमता इसके क्रियान्वन के लिए कोई विवरण जारी नहीं किया गया जिस से तीसरे पक्ष के विक्रेताओं के लिए NTFS को सँभालने के टूल उपलब्ध कराना मुश्किल बना दिया। Linux NTFS को पढ़ने और लिखने की क्षमता NTFS-3 जी ड्राईवर द्वारा प्रदान की गई है। यह ज्यादातर Linux वितरण में शामिल है। अन्य पुराने और ज्यादातर केवल पढ़ने के समाधान भी मौजूद हैं: Linux Kernel 2.2 : Kernel संस्करण 2.2.0 और बाद में NTFS विभाजन पढ़ने की क्षमता शामिल है। Linux Kernel 2.6: Kernel संस्करण 2.6.0 और बाद में एक ड्राईवर एंटोन अलतापर्माकोव (कैम्ब्रिज विश्वविद्यालय) और रिचर्ड रुस्सों द्वारा लिखा गया। यह फ़ाइल को पढ़ने, ओवरराइट करने तथा साइज़ बदलने में सहायता करता है। NTFSMount: एक पढ़ने/लिखने वाला यूज़र स्पेस ड्राईवर. यह फ़ाइल कंप्रेशन व कूटबद्ध लेखन, फ़ाइल के स्वामित्व में परिवर्तन और उपयोग के अधिकार को छोड़कर NTFS को पढ़ने-लिखने की सुविधा प्रदान करता है।http://wiki.linux-ntfs.org/doku.php?id=ntfsmount linux-ntfs.org पर "ntfsmount wiki पेज" 8 जनवरी 2010 https://web.archive.org/web/20070927213220/http://wiki.linux-ntfs.org/doku.php?id=ntfsmount 27 सितंबर 2007 dead Linux के लिए NTFS: एक कमर्शियल ड्राईवर जिसे Paragon द्वारा पढ़ने/लिखने की सुविधा उपलब्ध है। कैप्टिव NTFS: एक 'wrapping' ड्राइवर है जो Windows का अपना ड्राइवर, ntfs.sys का प्रयोग करता है। ध्यान दें कि सभी तीन यूज़रस्पेस ड्राइवर, अर्थात् NTFSMount, NTFS-3 जी और कैप्टिव NTFS,फ़ाइल सिस्टम पर यूज़रस्पेस(FUSE) में बने हैं, जोकि एक Linux मॉड्यूल है जिसे यूज़रस्पेस की ब्रिजिंग तथा Kernel कोड को सेव करने तथा डाटा पुनः प्राप्त करने का जिम्मा सौंपा गया है। उपरोक्त बताये गए लगभग सभी ड्राइवर (Linux के लिए Paragon NTFS को छोड़कर) खुले स्रोत (GPL) हैं। NTFS की आंतरिक संरचनाओं की जटिलता के कारण, खराब होने से बचने के लिए दोनों आंतरिक-2.6.14 Kernel ड्राइवर और फ्यूज ड्राइवर उस वोल्यूम में परिवर्तन को अनुमति प्रदान नहीं करते जिसे वे असुरक्षित समझते हैं। मैक OS X मैक OS X v10.3 और बाद के संस्करणों में NTFS द्वारा फॉर्मेट किये गये पार्टीशन को केवल पढ़ने की क्षमता है। GPL द्वारा लाइसेंस प्राप्त NTFS-3G भी FUSE के माध्यम से मैक OS X पर काम करता है तथा NTFS विभाजन पर पढ़ने तथा लिखने की अनुमति देता है। मैक OS X के लिए एक साथ पढ़ने/लिखने का अधिकार प्राप्त करने का एकमात्र उपाय "मैक OS X के लिए पैरागोन NTFS" है।http://www.paragon-software.com/home/ntfs-mac मैक OS X के लिए पैरागोन NTFS - मैक OS X के तहत Windows NTFS पार्टीशन तक पढ़ने तथा लिखने की पूरी पहुंच 8 जनवरी 2010 https://web.archive.org/web/20100105052739/http://www.paragon-software.com/home/ntfs-mac/ 5 जनवरी 2010 live NTFS पर लिखने में सहायक प्रोग्राम मैक OS X 10.6 में पाया गया है, लेकिन 10.6.1 संस्करण में सक्रिय नहीं किया गया है, हालांकि क्रियान्वित करने के लिए Hacks मौज़ूद हैं। Microsoft Windows जबकि अलग NTFS संस्करणों के अधिकांश भाग पूरी तरह से आगे और पीछे जाने में सक्षमहैं, Microsoft Windows के पुराने संस्करणों में नए NTFS संस्करणों पर कुछ तकनीकी कारणों से परेशानियाँ हैं। ये दोहरी बूटिंग और बाहरी पोर्टेबल हार्ड ड्राइव को प्रभावित करता है। उदाहरण के लिए, एक ऑपरेटिंग सिस्टम, जो सहायक नहीं है, पर NTFS पार्टीशन पर पिछला संस्करण (अथार्त वोल्यूम शैडो कॉपी) प्राप्त करने की कोशिश करने के परिणामस्वरूप पिछले संस्करण की सामग्री खो जायेगी.http://blogs.technet.com/filecab/archive/2006/07/14/441829.aspx How restore points and other recovery features in Windows Vista are affected when dual-booting with Windows XP cfsbloggers July 14, 2006 The Filing Cabinet 2007-03-21 https://web.archive.org/web/20060718011852/http://blogs.technet.com/filecab/archive/2006/07/14/441829.aspx 18 जुलाई 2006 dead अन्य OpenSolaris, eComStation, KolibriOS, और FreeBSD केवल पढ़ने के लिए NTFS स्पोर्ट देते हैं (बीटा NTFS ड्राईवर eComStation को लिखने/मिटाने की अनुमति देता है, लेकिन आमतौर पर असुरक्षित माना जाता है). एक अन्य तीसरा उपकरण BeOS, जो NTFS-3G पर आधारित था, NTFS के लिए पढ़ने और लिखने की अनुमति देता है। NTFS-3 G भी FUSE के माध्यम से Linux के अलावा मैक OS X, FreeBSD, NetBSD, Solaris और Haiku पर काम करती है।http://www.ntfs-3g.org/ NTFS-3G Stable Read/Write Driver 2009-07-25 8 जनवरी 2010 https://web.archive.org/web/20090917181509/http://www.ntfs-3g.org/ 17 सितंबर 2009 live एक मुफ्त निजी प्रयोग के लिए पढ़ने/लिखने का MS-DOS का ड्राईवर "NTFS4DOS" भी मौजूद है।http://www.free-av.com/en/tools/11/avira_ntfs4dos_personal.html संग्रहीत प्रति 8 जनवरी 2010 https://web.archive.org/web/20100619161828/http://www.free-av.com/en/tools/11/avira_ntfs4dos_personal.html 19 जून 2010 dead FAT से संगतता (कम्पेटिबिलिटी) Microsoft वर्तमान में एक उपकरण (convert.exe) प्रदान करता है जो HPFS(केवल Windows NT 3 पर),FAT16 Windows 2000 और उच्च संस्करण और FAT32 को NTFS में बदल देता है, लेकिन इसका कोई दूसरा तरीका नहीं है।http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/convertfat.mspx How to Convert FAT Disks to NTFS 2007-08-27 2001-10-25 Microsoft Corporation https://web.archive.org/web/20080203152527/http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/convertfat.mspx 3 फ़रवरी 2008 live विभिन्न तीसरी पार्टी उपकरण भी सुरक्षित NTFS पार्टीशन रीसाइज़िंग में सक्षम हैं। Microsoft ने Windows Vista में पार्टीशन को सिकोड़ने तथा बड़ा करने की क्षमता जोड़ी है, लेकिन यह क्षमता सीमित है क्योंकि यह पेज फ़ाइल फ्रेग्मेंट्स या स्थानांतरित न होने वाली फ़ाइल को नहीं हटाएगा, अतः पार्टीशन को सिकोड़ने की क्षमता सीमित है। एक पेज फ़ाइल के बिना रीबूटिंग या डीफ्रेगमेंट करने के लिए किसी तीसरे टूल का उपयोग स्थिति को खराब कर सकता है यदि पेज फ़ाइल हटने वाली फ़ाइल नहीं है। ऐतिहासिक कारणों से, Windows के संस्करण जोकि NTFS का समर्थन नहीं करते, सभी आंतरिक रूप से समय को स्थानीय समय क्षेत्र के रूप में रखते हैं और NTFS के अलावा बाकी फ़ाइल सिस्टम भी ऐसा ही करते हैं जिन्हें Windows का वर्तमान संस्करण सहायता कर रहा है। तथापि, Windows NT और आने वाले संस्करण UTC के रूप में आंतरिक टाइम स्टाम्प्स रखते हैं और प्रदर्शन के लिए उपयुक्त परिवर्तन करते हैं। इसलिए, UTC में NTFS टाइम स्टाम्प्स हैं। इसका मतलब यह है कि जब फाईलें NTFS और नॉन-NTFS पार्टीशन के बीच कॉपी या स्थानांतरित की जाती है, तो OS को फ्लाई पर टाइम स्टाम्प्स बदलने की आवश्यकता पड़ती है। लेकिन अगर कुछ फ़ाइलें जब डे-लाइट सेविंग टाइम(DST) के अंतर्गत स्थानांतरित की जाती हैं और अगर कुछ फ़ाइलें मानक समय के अंतर्गत स्थानांतरित की जाती हैं तो रूपांतरण के दौरान विसंगतियां हो सकती हैं। परिणामस्वरूप, किसी एक दिन बाद जब स्थानीय समय क्षेत्र बदलता है, यूज़र यह जान सकते हैं कि कुछ फाईलों के टाइम स्टाम्प्स में 1 घंटे की गलती है। डीएसटी को लागू करने में उत्तरी और दक्षिणी गोलार्द्धों के बीच मतभेद के चलते, किसी भी 12 महीने में एक संभावित टाइमस्टैम्प में 4 घंटे तक की त्रुटि हो सकती है।बीटिंग द डे-लाइट सेविंग टाइम बग https://web.archive.org/web/20041114032240/http://www.codeproject.com/datetime/dstbugs.asp 14 नवंबर 2004 तथा फ़ाइल का सुधार समय सही करना "द कोड प्रोजेक्ट" इंटरनल्स NTFS में, सभी फ़ाइल डाटा - फ़ाइल नाम, निर्माण तिथि, नियंत्रण अनुमति और सामग्री-मास्टर फ़ाइल तालिका में मेटाडाटा के रूप में जमा हो जाता है। इस सुविधा ने Windows NT फ़ाइल प्रणाली के विकास के दौरान फ़ाइल सिस्टम सुविधाओं को आसानी से जोड़ना संभव बनाया। - एक्टिव डायरेक्टरी सॉफ्टवेयर द्वारा इंडेक्सिंग के लिए फील्ड्स को जोड़ना एक दिलचस्प उदाहरण है। NTFS नाम एन्कोडिंग के लिए 16-बिट वैल्यू के किसी भी क्रम को अनुमति देता है (फ़ाइल नाम, स्ट्रीम नाम, इंडेक्स नाम आदि). इसका मतलब यह है UTF-16 कोड पॉइंट्स का समर्थन किया जाता है लेकिन फ़ाइल सिस्टम यह जांच नहीं करता कि क्रम वैध UTF-16 है (यह यूनीकोड मानक तक ही सीमित नहीं है तथा कम वैल्यू के किसी भी क्रम को अनुमति देता है). आंतरिक रूप से, NTFS फ़ाइल सिस्टम डाटा को इंडेक्स (क्रमवार) करने के लिए बी+ ट्री का उपयोग करता है। हालांकि यह लागू करने में कठिन है, ज्यादातर मामलों में यह फ़ाइल को तेज़ी से खोजता है। एक फ़ाइल सिस्टम जर्नल फ़ाइल सिस्टम मेटाडाटा की अखंडता की गारंटी देता है लेकिन व्यक्तिगत फाईलों की सामग्री की नहीं। सिस्टम जो NTFS का उपयोग करते हैं उन्हें FAT फ़ाइल सिस्टम की तुलना में विश्वसनीय माना जाता है।http://www.microsoft.com/technet/archive/ntwrkstn/reskit/file_sys.mspx?mfr=true "Microsoft TechNet Resource Kit" 8 जनवरी 2010 https://web.archive.org/web/20080224040805/http://www.microsoft.com/technet/archive/ntwrkstn/reskit/file_sys.mspx?mfr=true 24 फ़रवरी 2008 live मास्टर फ़ाइल तालिका (MFT) हर फ़ाइल, डायरेक्टरी और NTFS वोल्यूम पर मेटाफ़ाइल की मेटाडाटा के रूप में जानकारी रखती है। इसमें फ़ाइल नाम, स्थान, साइज़ और अनुमति भी शामिल है। इसकी संरचना एल्गोरिदम, जो डिस्क विखंडन कम से कम करती है, का समर्थन करती है। एक डायरेक्टरी प्रविष्टि में एक फ़ाइल नाम और "फ़ाइल ID" होता है जो मास्टर फ़ाइल तालिका में फ़ाइल की रिकॉर्ड संख्या को प्रदर्शित करता है। फ़ाइल ID गिनती का पुनः प्रयोग पुराने सन्दर्भों का पता लगाने के लिए करते हैं। हालांकि यह फ़ाइल-11 के W_FID से अत्यधिक मिलता है, अन्य NTFS संरचनाएं मौलिक रूप से अलग दिखती हैं। मेटा फ़ाइलें NTFS कई फ़ाइलों से मिल कर बना है जो फ़ाइल सिस्टम को परिभाषित तथा व्यवस्थित करती हैं। सभी मामलों में, ये फाइलें किसी भी अन्य यूज़र फाईलों की तरह बनी होती हैं ($ वोल्यूम सबसे अलग है), लेकिन फ़ाइल सिस्टम के ग्राहकों की इसमें प्रत्यक्ष रुचि नहीं होती.ये मेटा फ़ाइलें, फाईलों को परिभाषित करती हैं, फ़ाइल सिस्टम डाटा की महत्वपूर्ण फ़ाइलों का बैकअप रखती हैं, तथा बफर फ़ाइल सिस्टम में परिवर्तन, मुक्त स्थान आबंटन प्रबंधन,BIOS की अपेक्षाओं को पूरा करना, खराब आवंटन इकाइयों को खोजना, सुरक्षा तथा डिस्क स्थान उपयोग की जानकारी को संग्रहण करने का कार्य करती हैं। जब तक कहीं ओर इंगित न की जायें, सभी सामग्री एक अनाम डाटा स्ट्रीम में है। क्षेत्र संख्या फ़ाइल का नाम उद्देश्य: 0 $ MFT वोल्यूम पर सभी फाइलों का वर्णन, जिसमें फ़ाइल नाम, टाइम स्टांप, स्ट्रीम के नाम शामिल है और क्लस्टर की संख्या जहां डाटा स्ट्रीम रहते हैं, इंडेक्स, सुरक्षा को पहचानने के कारक और फ़ाइल गुण जैसे 'केवल पढ़ने","संकुचित","एन्क्रिप्टेड ", इत्यादि. 1 $ MFTMirr पहली महत्वपूर्ण प्रविष्टियों का डुप्लीकेट $ MFT है, आमतौर पर 4 प्र्विशितियाँ होती हैं 4 KiB. 2 LogFile $ फ़ाइल सिस्टम मेटाडाटा का ट्रांसेक्शन लॉग रखती है। 3 $ Volume वोल्यूम के बारे में जानकारी, अर्थात् वोल्यूम ऑब्जेक्ट पहचानकर्ता,वोल्यूम लेबल, फ़ाइल सिस्टम संस्करण और वॉल्यूम फ्लैग्स (स्थापित, chkdsk अनुरोध, $LogFile आकार परिवर्तन का अनुरोध, NT 4 पर स्थापना, वोल्यूम क्रम संख्या को अपडेट करना, संरचना अपडेट करने का अनुरोध). यह डाटा एक डाटा स्ट्रीम में संग्रहीत नहीं है, बल्कि विशेष MFT विशेषताओं में: यदि उपस्थित हों, $OBJECT_ID रिकॉर्ड में वोल्यूम ऑब्जेक्ट ID संग्रहित है; $VOLUME_NAME रिकॉर्ड में वोल्यूम लेबल संग्रहीत है और शेष वोल्यूम डाटा $VOLUME_INFORMATION रिकॉर्ड में है। नोट: वोल्यूम क्रम संख्या $बूट (नीचे) फ़ाइल में संग्रहित है। 4 $ AttrDef MFT गुणों की एक तालिका है जो संख्यात्मक पहचानकर्ता को नाम से जोड़ती है। 5 । रूट डायरेक्टरी. डायरेक्टरी डाटा $INDEX_ROOT और $INDEX_ALLOCATION में संग्रहीत है तथा दोनों का एट्रीब्यूट नाम $I30 है। 6 $ बिटमैप बिट प्रविष्टियों की एक सारिणी: प्रत्येक बिट संकेत करता है कि इसका क्लस्टर प्रयोग में (आवंटित) या खाली है (आवंटन के लिए उपलब्ध). 7 $ बूट वोल्यूम बूट रिकॉर्ड. यह फ़ाइल हमेशा वोल्यूम पर पहले क्लस्टर में स्थित है। इसमें बूटस्ट्रैप कोड (NTLDR /BOOTMGR देखें) और एक BIOS पैरामीटर ब्लॉक शामिल है जिसमें $MFT और $MFT की क्लस्टर संख्या और वोल्यूम सीरियल संख्या होती है। $बूट आम तौर पर 8,192 बाईट्स लंबा होता है। 8 $ BadClus एक फ़ाइल जिसमें सभी क्लस्टर खराब क्षेत्र के रूप में चिह्नित होते हैं। यह फ़ाइल chkdsk यूटिलिटी द्वारा क्लस्टर प्रबंधन को सरल करती है, व नए खराब क्षेत्रों की खोज और बिना सन्दर्भ के क्लस्टरों की पहचान करती है। इस फ़ाइल में दो डाटा स्ट्रीम हैं, बिना खराब क्षेत्र के वोल्यूम में भी, एक अनाम स्ट्रीम में खराब क्षेत्र होते हैं- पूर्ण रूप से सही वोल्यूम के लिए यह शून्य लम्बाई है, दूसरी स्ट्रीम का नाम $बैड है तथा इसमें वो सभी क्लस्टर होते हैं जो पहली स्ट्रीम में नहीं हैं।$BadClust: $BAD का प्रयोग विशेष रूप से वहां होता है जब इसके क्लस्टर के आवंटन से chkdsk द्वारा "मल्टीपल क्लस्टर संदर्भ" त्रुटी उत्पन्न नहीं होती. 9 $सुरक्षित डाटाबेस सूची तक पहुँच नियंत्रित करती है जो हर फ़ाइल के साथ एक जैसे ACL संग्रहित करने का खर्चा, सारे ACL को एक साथ विशिष्ट ढंग से संग्रहित करके कम कर देता है (इसमें दो सूचकांक $SII: जनवरी 2008 शायद सुरक्षा ID इंडेक्स और $SDH: सुरक्षा डिस्क्रिप्टर हैश वास्तविक अचल तालिका युक्त $SDS स्ट्रीम को इंडेक्स करता है). 10 UpCase $ यूनिकोड अपरकेस अक्षरों की एक तालिका जो Win32 और डॉस नाम स्थान में केस इनसेंसिटीविटी सुनश्चित करती है। 11 $EXtend एक फ़ाइल सिस्टम डायरेक्टरी जिसमें विभिन्न प्रकार के एक्सटेंशन होते हैं जैसे $Quota, $ObjId,$Reparse या $UsnJrnl. 12...23 $MFT विस्तार प्रविष्टियों के लिए आरक्षित.एक्सटेंशन प्रविष्टियां अतिरिक्त MFT रिकॉर्ड हैं जिनमें अतिरिक्त गुण होते हैं तथा जो प्राथमिक रिकॉर्ड में फिट नहीं होते हैं। फ़ाइल के पर्याप्त फ्रेगमेंटेड होने, कई स्ट्रीम के होने, लम्बे फ़ाइल नाम, जटिल सुरक्षा या अन्य दुर्लभ स्थितियों में ऐसा हो सकता है। आम तौर पर 24 $Extend\$Quota डिस्क कोटा की जानकारी रखती है। इसमें $O तथा $Q दो इंडेक्स रूट होते हैं। आम तौर पर 25 $Extend\$ObjId{{/0} डिस्ट्रीब्यूटेड लिंक ट्रैकिंग की जानकारी रखती है। $O नाम की इंडेक्स रूट और आबंटन तालिका रखती है। आम तौर पर 26 $ extend \ Reparse $ रिपार्स पॉइंट डाटा रखती है (जैसे सिम्बोलिक लिंक्स). $R नाम की इंडेक्स रूट और आबंटन तालिका रखती है। 27 ... file.ext नियमित रूप से फ़ाइल प्रविष्टियों की शुरुआत. इन मेटा फाईलों को विशेष रूप से Windows द्वारा प्रयुक्त किया जाता है और इन्हें सीधे देख पाना मुश्किल है: देखने के लिए विशेष टूल्स की आवश्यकता पड़ती है।Windows XP के बाद से इन फ़ाइलों की सूची देखना बहुत मुश्किल है: वे रूट डायरेक्टरी की सूची में हैं लेकिन Win32 इंटरफेस उन्हें अलग कर देता है। NT 4.0 में, कमांड लाइन dir कमांड रूट डायरेक्टरी में मेटा फ़ाइलों की सूची दिखाएगी अगर /a एक साथ में निर्दिष्ट किया गया था। Windows 2000, में dir /a ने काम करना बंद कर दिया है, लेकिन dir / a \ $MFT कमांड अब भी काम करती है। MFT रिकॉर्ड से एट्रीब्यूट सूची, गुण विशेषता तथा स्ट्रीम्स MFT रिकॉर्ड में वर्णित प्रत्येक फ़ाइल (या डायरेक्टरी) के लिए स्ट्रीम डिस्क्रिप्टर का एक भंडार है (जिसे एट्रीब्यूट के नाम से भी जाना जाता है), जो एक अनिश्चित लम्बाई के रिकॉर्ड (जिसे एट्रीब्यूट सूची के नाम से भी जाना जाता है), में एक साथ पैक होते हैं, हर MTF रिकॉर्ड को भरने के लिए निश्चित 1KB साइज़ की पैडिंग होती है और यह फ़ाइल के साथ प्रभावी स्ट्रीम्स के विषय में वर्णन करते हैं। प्रत्येक स्ट्रीम (याएट्रीब्यूट) का एक सिंगल प्रकार (आंतरिक रूप से निश्चित साइज़ की पूर्ण संख्या जो डिस्क्रिप्टर में संग्रहित है, लेकिन ज्यादातर बराबर के फ़ाइल नाम फाइल ओपन () या फाइल क्रिएट () API कॉल प्रोग्राम द्वारा नियंत्रित की जाती है), एक वैकल्पिक सिंगल स्ट्रीम नाम (जिनका वर्तमान फ़ाइल नाम से कोई सम्बन्ध न हो) तथा उस स्ट्रीम के साथ जुड़ा वैकल्पिक डाटा. NTFS के लिए, फ़ाइल का मानक डाटा, या डायरेक्टरी के लिए इंडेक्स डाटा उसी ढंग से नियंत्रित होते हैं जैसे दूसरी डाटा स्ट्रीम या मानक एट्रीब्यूट के लिए किये जाते हैं। वे केवल एक या कई एट्रीब्यूट सूची में संग्रहित एट्रीब्यूट में से एक हैं। MFT रिकॉर्ड में वर्णित प्रत्येक फ़ाइल के लिए (या स्ट्रीम डिस्क्रिप्टर की नॉन-रेसिडेंट रिपोजिट्री, नीचे देखें), स्ट्रीम डिस्क्रिप्टर की पहचान (स्ट्रीम वैल्यू प्रकार, स्ट्रीम का नाम) अद्वितीय होनी चाहिए। अतिरिक्त रूप से, NTFS में डिस्क्रिप्टर के साथ ऐसा करने में कुछ बाधाएं हैं। यह एक पूर्वनिर्धारित रिक्त स्ट्रीम प्रकार है जिसका प्रयोग उस फ़ाइल की स्ट्रीम रिपोजिट्री में स्ट्रीम डिस्क्रिप्टर की सूची का अंत प्रदर्शित करने के लिए किया जाता है। इसे प्रत्येक स्ट्रीम रिपोजिट्री के अंतिम स्ट्रीम डिस्क्रिप्टर में उपस्थित होना चाहिए। (इसके बाद दूसरे संग्रहण स्थान नज़रंदाज़ कर दिए जायेंगे तथा MFT में रिकॉर्ड के साइज़ को या नॉन-रेसिडेंट स्ट्रीम रिपोजिट्री में क्लस्टर साइज़ को मैच करने के लिए पैडिंग बाइट्स रहेंगे). स्ट्रीम के कुछ प्रकारों की आवश्यकता पड़ती है तथा ये प्रत्येक MTF रिकॉर्ड में उपस्थित होने चाहिए सिवाए अप्रयुक्त रिकार्डों के जिन्हें स्ट्रीम द्वारा रिक्त स्ट्रीम प्रकार द्वारा पर्दर्शित किया जाता है। मानक एट्रीब्यूट के केस में जो निश्चित साइज़ रिकॉर्ड की तरह संग्रहित होते हैं तथा जिनमें टाइम स्टांप तथा दूसरे सिंगल बिट एट्रीब्यूट होते हैं। (डॉस में FAT/FAT32 या Windows 95/98 द्वारा प्रबंधित एप्लीकेशंस के साथ सामंजस्य है) कुछ स्ट्रीम प्रकारों का नाम नहीं हो सकता तथा उन्हें गुमनाम ही रहना चाहिए। मानक एट्रीब्यूट के केस में, या फिर प्राथमिकता प्राप्त NTFS "फ़ाइल नाम" प्रकार की स्ट्रीम, या "छोटा फ़ाइल नाम" प्रकार की स्ट्रीम भी उपस्थित हों.(डॉस की तरह की एप्लीकेशंस के साथ सामंजस्य के लिए).यह भी संभव है एक फ़ाइल का केवल एक छोटा फ़ाइल नाम, उस मामले में यह Windows Explorer की सूची में प्रथम स्थान पर होगी। स्ट्रीम रिपोजिट्री में संग्रहित फ़ाइल नाम स्ट्रीम शाखाक्रम फ़ाइल सिस्टम के अनुसार फ़ाइल को एकदम उपलब्ध नहीं कराते. वास्तव में, सभी फ़ाइल नाम कम से कम एक अलग डायरेक्टरी में अपनी MTF प्रविष्टि, सुरक्षा डिस्क्रिप्टर और एट्रीब्यूट, जो उस फ़ाइल की MTF प्रविष्टी संख्या बतायेगा, के साथ एक ही वोल्यूम पर अलग से क्रमबद्ध होने चाहियें. यह एक ही वोल्यूम पर कई जगहों पर संभवतः अलग फ़ाइल नामों के साथ एक ही फ़ाइल या डायरेक्टरी के हार्ड लिंक की अनुमति देता है। एक नियमित फ़ाइल की डिफाल्ट डाटा स्ट्रीम $DATA लेकिन अनाम फ़ाइल नाम तथा समान AD के साथ है किन्तु इसका नामकरण होना चाहिए। इसके विपरीत डायरेक्टरी की डिफॉल्ट डाटा स्ट्रीम अलग प्रकार की है लेकिन अनाम नहीं है। इनका स्ट्रीम नाम (NTFS 3+ में "$I30") है जो इंडेक्सिंग प्रारूप को दर्शाता है। रेसिडेंट बनाम नॉन-रेसिडेंट डाटा स्ट्रीम संग्रहण की क्षमता बढाने तथा छोटा डाटा के साथ जुडी स्ट्रीम के I/O खर्चे कम करने के लिए, NTFS MTF प्रविष्टी के द्वारा क्लस्टर सूचीबद्ध करने के बजाए स्ट्रीम डिस्क्रिप्टर में डाटा डालने को प्राथमिकता देता है। (यदि स्ट्रीम डिस्क्रिप्टर का साइज़ MTF रिकॉर्ड के अधिकतम साइज़ या नॉन-रेसिडेंट रिपोजिट्री की सिंगल प्रविष्टी के साइज़ से ज्यादा न हो). इस केस में स्ट्रीम डिस्क्रिप्टर सीधे ही डाटा को संग्रहित नहीं करेगा लेकिन एक आबंटन मानचित्र पर संग्रहण करेगा जो वोल्यूम पर अन्यत्र संग्रहित डाटा को इंगित करेगा। जब स्ट्रीम डाटा को स्ट्रीम डिस्क्रिप्टर से सीधे प्राप्त किया जा सकता है, तो इसे कंप्यूटर फोरेंसिक्स कार्यकर्ताओं द्वारा "रेसिडेंट डाटा" कहा जाता है। डाटा की मात्रा फ़ाइल विशेषताओं पर बहुत निर्भर है, लेकिन छोटे फ़ाइल नाम तथा बिना ACL के 700-800 बाइट्स सिंगल स्ट्रीम फ़ाइलों में आम है। कुछ स्ट्रीम डिस्क्रिप्टर को नॉन-रेसिडेंट नहीं बनाया जा सकता.(जैसे पसंदीदा फ़ाइल नाम, या नॉन-रेसिडेंट स्ट्रीम के लिए मुख्य आबंटन नक्शा). NTFS द्वारा एनक्रिप्टेड, स्पार्स डाटा स्ट्रीम या संपीडित डाटा स्ट्रीम को रेसिडेंट नहीं बनाया जा सकता. नॉन-रेसिडेंट स्ट्रीम के लिए आबंटन मानचित्र का प्रारूप स्पार्स डाटा संग्रहण की क्षमता पर निर्भर करता है। NTFS के वर्तमान क्रियान्वन मैं, जब एक बार नॉन-रेसिडेंट डाटा स्ट्रीम को चिन्हित कर दिया जाए और स्पार्स में बदला जाए तो इसे नॉन-स्पार्स डाटा में नहीं वापिस लाया जा सकता है इसलिए यह दोबारा रेसिडेंट नहीं बन सकता जब तक डाटा स्पार्स आबंटन मानचित्र को छोड़ कर पूरी तरह से काट कर छोटा न कर दिया जाए. जब एक नॉन-रेसिडेंट डाटा स्ट्रीम को अत्यधिक फ्रेगमेंट किया जाता है तो इसका आबंटन मानचित्र MFT प्रविष्टी में फिट नहीं होता, तो आबंटन मानचित्र को नॉन-रेसिडेंट स्ट्रीम में भी संग्रहित किया जा सकता है, जिसमें एक छोटी रेसिडेंट स्ट्रीम में संग्रहित अप्रत्यक्ष आबंटन मानचित्र होता है जो नॉन-रेसिडेंट डाटा स्ट्रीम में संग्रहित नॉन-रेसिडेंट आबंटन मानचित्र को दर्शाता है। जब एक फ़ाइल में बहुत सारी स्ट्रीम हों (जिसमें एड्स, विस्तृत एट्रीब्यूट या सुरक्षा डिस्क्रिप्टर शामिल हों), जिसके कारण उनके डिस्क्रिप्टर MTF रिकॉर्ड में फिट न हो सकें, तो एक नॉन-रेसिडेंट स्ट्रीम का प्रयोग दूसरे डाटा डिस्क्रिप्टर (उन छोटी स्ट्रीम को छोड़ कर जो नॉन-रेसिडेंट नहीं हो सकतीं) की अतिरिक्त रिपोजिट्री को संग्रहित करने में किया जा सकता है, इसमें उसी प्रारूप का प्रयोग होता है जो MTF रिकॉर्ड में होता है लेकिन इसमें MTF रिकॉर्ड की अपेक्षा स्थान सीमित है। NTFS फ़ाइल सिस्टम ड्राईवर कभी कभी स्ट्रीम रिपोजिट्री में नॉन-रेसिडेंट स्ट्रीम को डालने का प्रयास करता है तथा नॉन-रेसिडेंट रिपोजिट्री में संग्रहित स्ट्रीम डिस्क्रिप्टर को MFT रिकॉर्ड की स्ट्रीम रिपोजिट्री में डालने का भी प्रयास करता है। यह प्रयास प्राथमिकता और प्राथमिकता के आधार पर आदेश के नियम और आकार पर निर्भर हैं। चूंकि रेसिडेंट फाईलें क्लस्टर ("आवंटन इकाइयों") पर कब्ज़ा नहीं करतीं, इसलिए एक NTFS वोल्यूम पर क्लस्टर से ज्यादा फ़ाइल नामों का होना संभव है। उदाहरण के लिए, एक 80 GB पार्टीशन (74.5GiB) के 4KiB के 19,543,064 क्लस्टर हो सकते हैं। सिस्टम फाईलों (64 MiB log फ़ाइल, 2,442,888 बाइट्स की $बिटमैप फ़ाइल तथा 25 फिक्स क्लस्टर के साथ) को घटाने के पश्चात् 19,526,158 क्लस्टर फाईलों तथा सूचियों के लिए खाली हैं। क्योंकि एक क्लस्टर में 4 MFT रिकॉर्ड हैं, यह वोल्यूम सैद्धांतिक रूप से लगभग 4 × 19,526,158 = 78,104,632 रेसिडेंट फ़ाइलों को संभाल सकता है। सीमाएं NTFS की कुछ निम्नलिखित सीमाएं हैं: आरक्षित फ़ाइल नाम हालांकि फ़ाइल सिस्टम पाथ का 32,767 यूनीकोड अक्षरोंइसके अतिरिक्त, 32,767 resp. 255 UTF-16 code शब्द. कुछ दुर्लभ/असामान्य यूनिकोड अक्षरों को ऐसे दो शब्दों की आवश्यकता है। का समर्थन करता है जिसमें प्रत्येक पाथ (डायरेक्टरी या फ़ाइल का नाम) 255 अक्षर तक का हो सकता है, कुछ नामों का प्रयोग नहीं किया जा सकता क्योंकि NTFS अपना मेटाडाटा नियमित (छिपी हुईं तथा ज्यादातर भाग पहुँच से बाहर होते हैं) फाईलों में संग्रहित करता है। ये फ़ाइलें रूट डायरेक्टरी में हैं (और केवल डायरेक्टरी के लिए ही आरक्षित हैं). इनके नाम नाम हैं: $MFT, $MFTMirr, $LogFile, $Volume, $AttrDef,. (dot), $Bitmap, $Boot, $BadClus, $Secure, $Upcase, तथा $Extend;. (dot) तथा $Extend दोनों डायरेक्टरी हैं तथा बाकी सभी फाईलें हैं। वोल्यूम का अधिकतम आकार (साइज़) सैद्धांतिक रूप से, NTFS वोल्यूम का अधिकतम साइज़ 264−1 क्लस्टर है। बहरहाल, Windows XP प्रोफेशनल में लागू किया गया NTFS वोल्यूम का अधिकतम आकार 232-1 क्लस्टर है। उदाहरण के लिए, 64 KiB क्लस्टर का प्रयोग कर के एक NTFS वोल्यूम का अधिकतम साइज़ 256 TiB - 64 KiB है। डिफॉल्ट क्लस्टर साइज़ 4 KiB का प्रयोग करके NTFS वोल्यूम का अधिकतम साइज़ 16 TiB - 4 KiB है। (ये दोनों Windows XP SP1 में में दी गयी 128 GiB की सीमा से काफी अधिक हैं।) क्योंकि मास्टर बूट रिकॉर्ड (MBR) पर पार्टीशन टेबल केवल 2 Tib पार्टीशन साइज़ तक का ही समर्थन करता है, 2 TiB से अधिक के NTFS वोल्यूम के लिए डायनेमिक या GPT वोल्यूम का ही प्रयोग किया जाना चाहिए. अधिकतम फ़ाइल साइज़ सिद्धांत : 16EiB - 1 KiB (264-210या 18,446,744,073,709,550,592 बाइट्स). क्रियान्वयन: 16 TiB - 64 KiB (244 − 216 or 17,592,185,978,880 बाइट्स) वैकल्पिक डाटा स्ट्रीम Windows सिस्टम वैकल्पिक डाटा स्ट्रीम को कॉल कर के संभाल या नहीं संभाल सकता है। यह ऑपरेटिंग सिस्टम, यूटिलिटी या रिमोट फ़ाइल सिस्टम पर निर्भर है। एक फ़ाइल का स्थानान्तरण कुछ डाटा स्ट्रीम खुली छोड़ सकता है। फ़ाइलों को कॉपी करने या मूव करने का एक सुरक्षित तरीका BackupRead और BackupWrite सिस्टम कॉल है, जो प्रोग्राम को कई स्ट्रीम में यह सुनिश्चित करने और बाधा पैदा करने वाली स्ट्रीम को जानने के लिए जाने की अनुमति देते हैं कि हर स्ट्रीम गंतव्य वोल्यूम पर लिखी जा सकती है कि नहीं. अधिकतम पाथ लम्बाई एक पूर्ण पाथ 32,767 वर्ण तक लम्बा हो सकता, एक भाग 255 अक्षरों तक सीमित है। सबसे खराब स्थिति में यह 128 डायरेक्टरी तक सीमित है, लेकिन व्यवहार में इस सीमा तक शायद ही कभी आता है। तिथि सीमा NTFS Windows NT के रूप में ही समय की गणना करता है: 64-बिट टाइम स्टांप की रेंज 1 जनवरी, 1601 से 28 मई, 60056 तक 10 मिलियन टिक्स (107) प्रति सेकंड है (अथार्त प्रत्येक टिक में 100 नेनो सेकंड). लेकिन व्यवहार में, सिस्टम घड़ी इतनी सटीक नहीं होती और केवल सबसे बेहतर उपलब्ध सटीक समय ही रखा जाता है (विशेषतया बेहतर सिस्टम घड़ी को बिना किसी अतिरिक्त हार्डवेयर स्पोर्ट के 10 मिली सेकंड,) इसके अलावा सभी टाइम स्टाम्प्स भी सटीक नहीं हैं : मानक एट्रीब्यूट (डॉस तथा Windows 95/98/ME से कम्पेटिबल) में सटीकता कम है तथा आखिरी बार फ़ाइल खोलने का समय (यदि सिस्टम रजिस्ट्री सेटिंग में इसे अक्षम न किया गया हो तो) फ़ाइल सिस्टम को तत्परता से नहीं बताया जाता और बड़े अंतरों से पूर्ण संख्या तक हो जाता है। कार्यक्षमता की कमी NTFS MFT फाईलों का कोई बैकअप नहीं रखता जो पार्टीशन पर संग्रहित किसी भी फ़ाइल का सन्दर्भ रखती हैं। यदि MFT मीडिया की खराबी के कारण क्षतिग्रस्त हो जाए तो सारा डाटा नष्ट हो सकता है। चूंकि इस डाटा का अकेला बैकअप MFT मिरर, MFT की सभी प्रविष्टियों को नहीं रखता, इसलिए महत्वपूर्ण डाटा को प्राप्त करना आसान नहीं है। डेवलपर्स NTFS डेवलपर्स में शामिल हैं: Custer Helen Inside the Windows NT File System 1994 Microsoft Press 978-1-55615-660-1 vii https://archive.org/details/insidewindowsntf00cust/page/ टॉम मिलर गैरी किमुरा ब्रायन एंड्रयू डेविड गोएबेल इन्हें भी देखें फ़ाइल सिस्टम की तुलना फ़ाइल-11: ods-2 में NTFS की तरह समानताएं है (उदाहरण के लिए INDEXF.SYS और $Mft और BITMAP.SYS और $Bitmap की तुलना करें। ) HPFS, OS/2 के लिए बनाया गया फ़ाइल सिस्टम ntfsresize Samba (सॉफ्टवेयर) सन्दर्भ June 2008 2 अतिरिक्त अध्ययन/पठन Bolosky, William J.; Corbin, Scott; Goebel, David; & Douceur, John R. http://research.microsoft.com/pubs/74261/WSS2000.pdf Single Instance Storage in Windows 2000 Microsoft Research & Balder Technology Group, Inc. PDF date Custer Helen Inside the Windows NT File System 1994 Microsoft Press 978-1-55615-660-1 registration https://archive.org/details/insidewindowsntf00cust Nagar Rajeev 1997 Windows NT File System Internals: A Developer's Guide O'Reilly 978-1-56592-249-5 registration https://archive.org/details/windowsntfilesys00naga बाहरी कड़ियाँ दस्तावेज़: Linux NTFS प्रोजेक्ट से NTFS डिस्क संरचना की गहन परिभाषा NTFS.com- डोक्युमेंटेशन और NTFS के लिए संसाधन Microsoft NTFS तकनीकी संदर्भ क्रियान्वयन NTFS-3G- NTFS-3G एक खुला स्रोत जो Linux, FreeBSD, मैक OS X, NetBSD, Solaris और Haiku के लिए NTFS ड्राईवर लिखता/पढ़ता है। Linux-NTFS- एक खुला स्रोत जो NTFS तक पहुँचने तथा उसमें हेरफेर के लिए Linux Kernel (लिखने का समर्थन सीमित है किन्तु सरल कार्यों के लिए प्रयुक्त हो सकता है) का समर्थन करता है तथा POSIX कम्पेटिबल यूटिलिटी को लिखता है। (ntfsprogs; includes ntfsls, ntfsresize, ntfsclone, आदि).Linux NTFS अकसर किये जाने वाले सवाल और कैसे करें कैप्टिव NTFS- कैप्टिव NTFS- एक परत जो Linux सिस्टम के तहत Windows NTFS ड्राईवर का प्रयोग NTFS फ़ाइल सिस्टम तक पहुँचने के लिए करता है। श्रेणी:माइक्रोसॉफ़्ट श्रेणी:डिस्क फ़ाइल सिस्टम श्रेणी:विण्डोज़ डिस्क फ़ाइल सिस्टम श्रेणी:विण्डोज़ के घटक श्रेणी:फ़ाइल कंप्रेशन सिस्टम्स