跳至內容

NTFS

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書
NTFS
開發者Microsoft
全稱New Technology File System
發佈1993年7月 (Windows NT 3.1)
分區標識主開機紀錄（MBR）:0x07
GUID磁碟分割表（GPT）:EBD0A0A2-B9E5-4433-87C0-68B6B72699C7（基本數據分區（BDP）)
結構
目錄內容B+樹[1]
檔案分配點陣圖
壞塊$BadClus（MFT記錄）
限制
最大檔案尺寸理論：16EiB-1KiB[2]
實際：16TiB-64KiB(Windows 7、Windows Server 2008 R2及以前版本)，256TiB-64KiB（Windows 8、Windows Server 2012及以後版本）[2]
最大檔案數量4,294,967,295（232-1）[2]
最長檔名255個UTF-16編碼單元[3]
最大卷容量理論：264-1簇[2]
實際：256 TiB-64 KiB[2]
檔案名字符集在POSIX命名空間中，非U+0000（NUL）和/（斜槓）的任何UTF-16碼元（大小寫敏感）。在Win32命名空間中，非U+0000（NUL）、/（斜槓）、\（反斜槓）、:（冒號）、*（星號）、?（問號）、"（引號）、<（小於號）、>（大於號）和 |（豎線或管道符）的任何UTF-16字元（大小寫不敏感）。[3]
功能
日期記錄建立、修改、POSIX更改、訪問
日期範圍1601年1月1日– 60056年5月28日（檔案時間為64位元數字，計時間隔為100納秒（每秒一千萬次），從1601年開始持續58000+年）
日期解像度100ns
岔流是（請參見下面的可選數據流）
屬性唯讀、隱藏、系統、存檔、內容未索引、離線、臨時
檔案系統權限存取控制列表（ACL）
透明壓縮對每個檔案，LZ77（Windows NT 3.51以上）
透明加密對每個檔案
DESX（Windows 2000以上）
Triple DES（Windows XP以上）
進階加密標準（AES）（Windows XP Service Pack 1、Windows Server 2003以上）
單一實例儲存（SIS）是
作業系統支援Windows NT 3.1以上
OSX 10.3以上（唯讀）
Linux內核版本2.6以上
Linux內核版本2.2-2.4（唯讀）
FreeBSD
NetBSD
Chrome OS
Solaris
ReactOS（唯讀）

NTFS（英語：New Technology File System），是Microsoft公司開發的專用檔案系統，從Windows NT 3.1開始成為Windows NT家族的預設檔案系統。它提供了一整套功能，包括安全描述符、加密、磁碟配額和豐富的元數據。 它可以和群集共用卷 (CSV) 一起使用，以提供可以從故障轉移群集的多個節點同時訪問的連續可用卷。[4][5]

NTFS取代FAT（檔案分配表）和HPFS（高效能檔案系統）並進行一系列改進成為更加完善的安全系統，例如增強對元數據的支援，使用更進階的數據結構以提升效能、可靠性和磁碟空間利用率，並附帶一系列增強功能，如存取控制列表（ACL）和檔案系統紀錄檔。

其他桌上電腦和伺服器作業系統也支援NTFS。Linux和windows提供代碼的軟件NTFS-system，可用於讀寫NTFS檔案。Mac OS X內核不能對NTFS進行寫入操作。

歷史

20世紀80年代中期，微軟（Microsoft）和IBM合作，希望建立下一代的圖形作業系統。該專案的成果為OS/2，但由於微軟和IBM在很多重要問題上無法達成共識，最後合作被終止，目前OS/2至今仍屬於IBM，而Microsoft從此後開始研究Windows NT。

OS/2的檔案系統HPFS包含許多重要功能，當Microsoft開始建立他們自己的新作業系統時，NTFS檔案系統的很多功能正是從HPFS中借鑑改善的。[6]可能正是因為他們來自於同一個專案，HPFS和NTFS使用相同的磁碟分區標識代碼（0x07）。這是一種非常特殊的情況，因為可用的標識碼並不匱乏，其它每個檔案系統具有自己的標識碼，例如，FAT擁有超過九個編號（FAT12、FAT16、FAT32等等各自都擁有不同的標識碼）。這種特例也導致之後用於區分檔案系統的演算法當遇到代碼0x07時候不得不進行額外的檢測。

NTFS的開發者包括：Tom Miller、Gary Kimura、Brian Andrew以及David Goebel。

版本

微軟正式發佈的NTFS版本有五個：

NTFS 版本號 首個支援的作業系統 發佈時間 新功能 備註
1.0 Windows NT 3.1 1993[5] 最初版本 v1.0和v1.1和之後的所有版本不相容。也即使用NT 3.5x寫入的卷無法被NT 3.1讀取。該問題的一個解決方案是使用NT 3.5x光碟更新NT 3.1，並添加對FAT系統的長檔名支援。[7]
1.1 Windows NT 3.51 1995 壓縮檔案、命名流、存取控制列表[1]
1.2 Windows NT 4.0 1996 安全描述符 Windows NT 4.0 作業系統發佈之後，該檔案系統版本號俗稱 NTFS 4.0
3.0 Windows 2000 2000 支援磁碟限額、加密、稀疏檔案、重解析點[來源請求]，更新序列數（USN）紀錄檔、$Extend資料夾（及其中的檔案），並改進安全描述符設計方案，允許使用同樣的安全設置的多個檔案共用一個安全描述符。[1] Windows NT 4.0 的 SP4 升級包對這個版本的NTFS提供了相容。

Windows 2000 作業系統發佈之後，該檔案系統版本號俗稱 NTFS 5.0。

3.1 Windows XP 2001 在MFT中提供冗餘MFT記錄數擴充項，可用於恢復受損的MFT檔案。 Windows XP 作業系統發佈之後，該檔案系統版本號俗稱 NTFS 5.1

NTFS.sys的檔案版本號（例如在 Windows 2000 裏面是 v5.0）是基於作業系統版本號的，不該與 NTFS 版本號（例如 Windows XP 裏面是 v3.1）混淆。[8]

後續的Windows的版本更新增加了許多檔案系統相關的功能，但並沒有改變NTFS本身。例如Windows Vista增加了NTFS符號連結、事務NTFS、磁碟收縮和自我修復，但除了符號連結外其他功能其實都由作業系統實現。

功能

相對於之前的版本，NTFS v3.0包含若干新功能：磁碟使用限額、稀疏檔案支援、重解析點、分佈連結跟蹤，以及檔案級加密（即「加密檔案系統（EFS）」）。

可伸縮性

理論上，NTFS卷的最大容量為264-1簇。在Windows XP專業版中，由於分區表限制，實際實現的最大容量為232-1簇。例如，在當簇的從大小為64 KiB時，Windows XP的NTFS卷的最大容量為256 TiB減去64 KiB；而當簇大小為預設的4 KiB時，卷最大容量將變為16 TiB減去4 KiB（但這都超過了Windows XP SP1對磁碟容量的128 GiB限制）。由於主開機紀錄（MBR）分區表最大支援單個分區容量為2 TiB，因此如果要建立超過2 TiB的NTFS卷，必須要使用動態卷或者GPT卷。注意：微軟預設的引導程式必須使用UEFI和64位元作業系統才能從GPT卷引導系統。

紀錄檔

NTFS是一個紀錄檔檔案系統，使用NTFS紀錄檔（$Logfile）記錄卷更改元數據。這是NTFS一個非常關鍵的功能（FAT/FAT32不提供此項功能），可確保其內部的複雜數據結構（如比較重要的如卷分配圖、磁碟重組API產生的數據轉移操作、MFT（主檔案表）記錄的更改情況（包括移動MFT記錄中儲存的變長屬性和屬性表等））和索引（在目錄和安全描述符中使用）即使在系統崩潰後仍然能保證一致性，而當在卷被重新載入後，可以非常容易地轉返這些關鍵數據的意外修改。

USN紀錄檔是一項系統管理功能，用於記錄卷中所有檔案、數據流、目錄的內容、屬性以及各項安全設置的更改情況。應用程式可以利用紀錄檔追蹤卷的更改。[9]對於非系統卷，可以選擇打開或關閉紀錄檔。[10]當添加一個新卷後，預設情況下紀錄檔功能處於打開狀態。

硬連結

硬連結可用於將不同的檔名直接關聯到同樣的檔案內容。

硬連結類似於目錄連接，但必須參照到檔案。硬連結只能連接到同一個卷內的檔案，因為每個卷擁有自己的主檔案表（MFT）。硬連結有自己的元數據，因此如果更改某個硬連結的檔案大小或尺寸，其他硬連結在被打開前可能不會自動更新這些資訊。

硬連結原本用於支援Windows NT的POSIX子系統[11]。

Windows使用硬連結實現對8.3檔名的支援。作業系統需要該功能，因為有些古老的應用程式只能使用短檔名。NTFS將會為檔案和目錄建立額外的NTFS記錄，但他們將總是自動同步更新（常規硬連結並不會同步更新）。

NTFS檔案系統限制單個檔案只能關聯到1024個硬連結。[12]

可選數據流（ADS）

可選數據流使單個檔案可以關聯到多個數據流。NTFS數據流的表述方式為「檔名:流名」，例如「text.txt:extrastream」。

NTFS流從Windows NT 3.1開始被引入，起初設計目的是為了Services for Macintosh（SFM）能夠正確儲存Macintosh的資源分岔。現在的Windows伺服器已經不再包含此功能，但很多第三方的Apple歸檔服務（AFP）產品（例如Group Logic的ExtremeZ-IP）仍然會繼續使用可選數據流。Internet Explorer和其它一些瀏覽器會在從網絡上下載的檔案中添加一個非常小的可選數據流，用於標記它們來自於外部網站（表示可能會存在安全風險），用戶在打開這些檔案前系統將會顯示一個確認提示。[13]當用戶表示不希望再次看到這個確認對話方塊的時候，這個可選流將會從下載的檔案中被直接刪除。

可選數據流不會顯示在Windows檔案總管中，也不會算入檢視檔案屬性時顯示的檔案大小。如果將檔案複製到FAT格式的磁碟、附加到電子郵件、上載到網站，或者移動到任何其它不支援可選流的位置上時，則只有主數據流會被保留下來，其它可選流將被全部丟棄，因此使用可選流來儲存重要數據很可能會發生意外。Microsoft提供了一個叫作Streams[14]的工具，用戶可以使用這個工具檢視卷中的可選流。從Windows Powershell 3.0版本開始，以下cmdlet支援對可選數據流進行操作：Add-Content、Clear-Content、Get-Item、Out-String、Remove-Item，以及Set-Item。[15]

有些媒體播放器也嘗試使用可選數據流記錄多媒體檔案的自訂元數據，用於管理媒體檔案。MPEG、OGG等格式通常在檔案內簽入資訊標籤記錄媒體資訊，但不是所有格式都支援這種設計，而使用可選數據流的好處正是他不會影響檔案本身的內容。在Windows中註冊外殼擴充程式後，系統就可以解析這些數據，然後可以在Windows檔案總管的資訊欄中顯示它們。但大部分媒體播放器還是選擇使用獨立資料庫而非可選數據流來儲存這些資訊，因為可選數據流可能帶來一些其它問題，一個典型問題是檔案上的資訊對於所有用戶都可見並且是共用的，因此使用可選數據流將無法根據不同用戶的安全設置和喜好進行分別管理和保護。

一些惡意軟件會使用可選數據流來隱藏程式碼，[16]不過不少惡意軟件掃描程式和特殊工具現在已經能夠檢查可選數據流中的內容。

檔案壓縮

NTFS能夠使用LZNT1演算法（LZ77演算法的一種變種）壓縮檔案。[17]檔案壓縮以16個簇為一個區塊進行，也即如果簇大小為4KB，則壓縮時單個區塊的大小為64KB。NTFS壓縮演算法支援的最大簇大小為 4KB，如果簇大小超過 4KB，則壓縮功能將不可用。[18] 如果壓縮可以將64KB數據壓縮到60KB或者更小，則NTFS會將多餘的4KB頁面視為稀疏檔案簇，認為他們未經寫入。對此類簇的隨機訪問的效能是可以接受的，作業系統只需跟蹤碎片連結即可。但如果處理大型可壓縮檔案，則會產生大量碎片，因為NTFS會將每個小於64KB的區塊都看成一個碎片區域。[19][20]微軟NTFS開發團隊的研究表明，在簇大小為4KB（預設設置）時，NTFS卷上壓縮檔案的合理最大尺寸應當在50-60GB之間。當簇大小更小時，最大尺寸也會減小。[21]硬碟空間受限的單用戶系統可以使用NTFS壓縮在處理小檔案（4KB到64KB，或者更大尺寸，具體範圍取決於壓縮比）時受益。小於900位元組的檔案將被直接儲存在MFT的目錄項中。[22]

快閃記憶體裝置（如固態硬碟）沒有傳統硬碟的磁頭移動延遲，因此對此類裝置，磁碟碎片的影響非常有限。具有快速多處理器系統的用戶可以通過壓縮應用程式檔案和數據以提升速度並降低磁碟空間使用率。[23]請注意，使用Sandforce控制器的SSD本身也會壓縮數據，但檔案系統壓縮會導致傳輸的數據量變少，因此I/O負載會降低。

數據壓縮的最佳目標是內容具有重複性、很少寫入、通常順序訪問，並且尚未被壓縮過的檔案。例如，紀錄檔檔案就是一種理想的壓縮目標。

壓縮系統引導時需要使用的檔案，如驅動程式、NTLDR、winload.exe，或者BOOTMGR，會導致系統無法正確啟動。[24]不過在較新版本的Windows系統中，重要的系統檔案會被禁止壓縮。

當在驅動器或目錄的「進階設置」中更改「將檔案進行壓縮」的設置時，每個檔案將被獨立進行壓縮或者解壓縮。

對於壓縮檔案的讀寫絕大部分時候是透明的[25]，但Microsoft建議避免對伺服器系統或者通過網絡共用的遠端設定檔進行壓縮，因為這可能增加處理器的負擔。[26]Microsoft建議不要壓縮超過30MB的檔案，因為這可能會產生效能問題。[來源請求]由於壓縮檔案會產生很多碎片，因此磁碟重組過程通常需要花費更長時間。

電腦系統中最慢的裝置通常不是CPU而是硬碟，因此NTFS壓縮通常可以更有效地利用慢速的非RAM儲存系統，節省空間和時間（前提是假設壓縮檔案的碎片不會連續存放） 。[27]

稀疏檔案

稀疏檔案是包含稀疏數據集的檔案，稀疏檔案只儲存檔案中各個有意義的片段，而片段之間的空白將被忽略，這種設計特別適合實際數據非常少、大部分區域空白的檔案。讀取檔案時，對任何被忽略的位置，檔案系統程式都會返回數據0，因此檔案內容看起來幾乎全是零。很多資料庫和科學程式使用稀疏檔案[28]。Microsoft實現對稀疏檔案的高效儲存支援，允許應用程式指定檔案的空（零）數據區域。讀取稀疏檔案的應用程式不需要做單獨處理，可以繼續使用常規方法讀取數據，作業系統將根據讀取的位置決定返回零或者實際數據。和壓縮檔案類似，磁碟限額對稀疏檔案的尺寸判斷以聲明大小而非實際佔用大小為準。[29][30]

卷影複製

卷影複製（VSC）服務通過將新覆寫的數據複製到卷影（寫入時複製）來儲存NTFS卷上的檔案和資料夾的歷史版本。當用戶請求恢復檔案的早期版本時，舊的檔案數據將會覆蓋新數據。該功能也使得數據備份程式可以存檔當前系統正在使用的檔案。對於負載較重的系統，Microsoft建議將卷影副本設置到單獨的磁碟上，以減小系統主要卷的I/O負載。

Windows Vista通過持久卷影副本實現系統還原和先前的版本功能。但舊版本的作業系統載入NTFS卷時，由於其無法辨識持久卷影副本的數據格式，這些副本將被刪除。

事務

在Windows Vista中，應用程式可以使用事務NTFS（Transactional NTFS，TxF）將一系列對檔案的更改歸組到一個事務中。事務能夠確保所有更改要麼同時生效，要麼同時作廢，並能確保在事務提交完成前，其它應用程式無法無法檢測到其中的更改。[31]

該技術使用和卷影複製類似的技術（也即寫入時複製）以確保在事務不成功時，被覆寫的數據可以安全地轉返。通用紀錄檔檔案系統的紀錄檔將記錄下尚未成功提交或者已經提交但尚未完全生效的事務（常見原因是事務的某個參與者在提交過程中系統意外崩潰）。

事務NTFS並不要求事務是本機NTFS卷的檔案操作，可以包含在其它位置的任意事務數據或操作，例如對其它卷、本地登錄檔、SQL資料庫中、系統服務或者遠端服務中的事務修改。所有這些事務使用Windows系統中的「分佈事務協調器（DTC）」服務在網絡級別協調所有參與者，以確保所有參與者都能接收到同樣的提交狀態，並傳輸所有經過確認的更改。分散式NTFS事務的一個典型例子是可以以事務方式建立一個網絡級別的分散式檔案系統，並且每個客戶端都保留每個檔案的準確的離線快取。

安全

在NTFS中，每個檔案或資料夾具有一個安全描述符，用於說明其所有者，並包含兩個安全控制列表（ACL）。

第一個列表被稱為自主訪問控制列表（DACL），用於描述是否允許或禁止特定的用戶或用戶組進行特定的操作（如讀取、寫入、執行或刪除）。例如，「C:\Program Files」資料夾可能被設定為允許所有用戶讀取並執行，但只有具有管理員權限的用戶才能修改其內容。Windows Vista為DACL增加了強制訪問控制功能。DACL是Windows Vista及後續作業系統的用戶帳戶控制功能的主要檢查點。

第二個列表被稱為系統訪問控制列表（SACL），用於描述對檔案或資料夾的特定行為是否應當被稽核，以及在操作成功後是否應當記錄操作。例如，企業可能會對高度敏感的檔案開啟稽核功能，這樣管理員就可以了解到是否有人嘗試刪除或複製這些檔案，以及他們的操作是否成功完成。

加密

主條目：加密檔案系統

加密檔案系統（EFS）提供對NTFS卷上任意檔案和資料夾的用戶透明的強保護。加密檔案系統需要與EFS服務、Microsoft的加密應用程式介面（CryptoAPI）以及EFS 檔案執行時庫（FSRTL）聯合工作。

EFS使用對稱金鑰（也被稱為「檔案加密金鑰（FEK）」）加密檔案，這比起使用非對稱金鑰加密在加密和解密大量數據時消耗的時間較少。該對稱金鑰使用一個和請求加密檔案的用戶相關的公鑰加密檔案的內容，加密後的數據儲存在被加密檔案的可選數據流中。當需要解密檔案時，檔案系統使用用戶的金鑰解密儲存在檔案頭中的對稱金鑰，然後使用該對稱金鑰解密檔案。這些操作在檔案系統級別完成，因此對用戶來說是透明的。[32]為了處理用戶遺失金鑰的情況，加密檔案系統中還支援多個附加解密金鑰，因此除用戶外，授權過的恢復代理也能訪問數據。NTFS提供的加密和壓縮功能是互相排斥的——如果同時希望加密和壓縮，則NTFS檔案系統級別只能打開其中一種功能，另一種功能需要使用其它第三方工具完成。

Basic、Home和MediaCenter版本的Windows上不支援EFS功能。要使用這個功能，必須安裝Professional、Ultimate或者伺服器版本的Windows，或者使用Windows域中的企業部署工具進行部署。

限額

磁碟限額是NTFS v3開始提供的功能。此功能允許電腦管理員在受支援的Windows作業系統上為每個用戶分別設定允許使用的磁碟空間閾值，或者跟蹤檢視每個用戶使用的磁碟空間使用量。管理員可以設定當某個用戶使用特定量的磁碟空間後收到「磁碟空間超限」的警告，甚至拒絕他們繼續佔用更多空間。如果有檔案或者目錄使用NTFS檔案壓縮，則磁碟限額管理的尺寸以壓縮後的實際尺寸為準。如果應用程式通過作業系統介面查詢用戶可用的剩餘磁碟空間大小，開啟限額後程式得到的大小將是在限額範圍內的剩餘空間，而不再是磁碟的總剩餘空間。

Basic、Home和MediaCenter版本的Windows不支援磁碟限額功能。要使用這個功能，必須安裝Professional、Ultimate或者伺服器版本的Windows，或者使用Windows域中的企業部署工具進行部署。

重解析點

主條目：NTFS重解析點

該功能從NTFS v3開始可用。該功能可以在用戶空間中為檔案或目錄添加一個關聯的重解析點屬性。當對象管理器（請參見Windows NT線執行）解析檔案系統名稱並遇到重解析點屬性時，它將「重新解析」名稱，具體做法是：Windows會將需要重解析的名稱傳遞給已經載入的所有檔案過濾驅動程式，每個過濾驅動程式都會檢查重解析數據並判斷自己是否和該重解析點相關聯。如果某個過濾驅動程式判定自己匹配該重解析點，則它將攔截這次檔案系統呼叫，然後執行對應的特定功能。重解析點是實現卷載入點、目錄連接、分層儲存管理、本機結構儲存，以及單實例儲存等功能的基礎。

卷載入點

類似於Unix 載入點，可以將一個卷的根目錄附加到另一個檔案系統的某個目錄下。這項功能可以讓驅動器不需要單獨的卷標（如C:或D:）就可以被訪問。

當卷被載入到另一個卷的某個目錄時，該目錄原來的內容將無法訪問，而被新載入的卷中的內容所代替。被載入的卷仍然可以繼續擁有獨立的卷標。NTFS檔案系統不允許卷之間相互載入。卷載入點可以是永久的，也可以是非永久的。前者在系統重新啟動後會自動載入，而後者需要手動重新載入。

被載入的卷可以使用NTFS外的其它檔案系統。一個常見的例子是，被載入的卷一個遠端共用的目錄，該目錄擁有自己的權限設置，並且能夠根據實際檔案系統的策略為當前作業系統設定特定的訪問權限。

目錄連接

類似於卷載入點，但目錄連接的連接目標是檔案系統中的某個其它目錄。例如，目錄C:\exampledir帶有一個目錄連接屬性，連接到D:\linkeddir。當用戶級別的應用程式訪問時，NTFS將自動把所有參照重新導向到D:\linkeddir。[1]目錄連接功能在概念上類似於Unix的目錄符號連結，但符號連結可以連接到任何目標，而NTFS目錄連接只允許連接到目錄。

目錄連接可以在控制台中通過命令MKLINK /J連接名目標目錄建立，使用RMDIR連接名刪除。目錄連接是永久性的，如果在客戶端訪問伺服器的目錄連接，則作業系統會使用被連結的目錄所屬的系統（或域）的安全設置。但連接本身可能擁有獨立的安全設置，並且刪除一個目錄連接不會同時刪除目標目錄。

有些目錄連接是Windows Vista系統建立的，用於保持和早期版本的Windows的相容性，例如系統驅動器中的Documents and Settings資料夾會被連接到同一個卷中的Users物理目錄上。這些目錄預設情況下是隱藏的，並且進行相關的安全設置，因此Windows檔案總管不允許外殼或者大部分應用程式直接打開它們，這樣的設置可能是為了防止用戶發現兩個看上去相同的資料夾，然後錯誤地刪除其中的某一個。預設情況下只有本機的SYSTEM帳戶或者的Administrators用戶組成員可以訪問這些目錄，這是考慮到這些帳戶安裝軟件的權限，而安裝時可能會產生相容性問題。

目錄連接屬於軟連結（即使目標目錄已經被刪除，他們也仍然存在），使用一種類似符號連結的方式工作（只不過對於目標位置和類型有額外的限制），但NTFS檔案系統對它們進行特殊最佳化，解析更快，相比於之後提出的NTFS 符號連結，目錄連接的開銷更小，且可以在伺服器端解析，因此可以在遠端共用目錄中使用它們。

符號連結

參見：NTFS符號連結

符號連結（或稱軟連結）從Windows Vista開始引入。[33]符號連結在客戶端解析，因此如果伺服器上共用一個符號連結，則客戶端訪問時將服從本機而非伺服器端的訪問限制。

符號連結可以連結到檔案（使用MKLINK符號連結目標文件名建立），也可以連結到目錄（使用MKLINK /D符號連結目標目錄建立）。和Unix符號連結不同的一點是，NTFS符號連結在建立的時候就要決定目標類型（目錄或檔案），但建立符號連結的時候並不需要目標已經存在或可以訪問，在訪問時才會實際檢查可訪問性。NTFS在訪問符號連結時也會檢查目標的類型，由於NTFS不允許在任何位置有目錄和檔案同名，因此如果目標名稱存在但是類型不正確，系統也會返回一個找不到目標的錯誤。

符號連結也可以參照遠端主機上的共用資料夾或者其中的檔案、子資料夾。但目標並不會被立即載入，而是在應用程式使用OpenFile()或者CreateFile() API請求打開目標的時候才載入到系統中。符號連結是永久的（重新啟動後仍然保留在對應的卷上），可以在命令列或者指令碼中使用DEL符號連結刪除它們。

分層儲存管理（HSM）

分層儲存管理是一種轉移一定時間不用的檔案到價值更低的儲存媒介中的方法。當檔案再次被訪問時，檔案上的重解析點將判定檔案需要被使用，並將檔案從儲存媒介中恢復出來。分層儲存不但可以節省儲存開銷，也可以提高作業系統的數據讀寫和執行效率。

本機結構儲存（NSS）

本機結構儲存是一種已經被Microsoft終止使用的ActiveX文件儲存技術。這項技術允許ActiveX文件使用和ActiveX內部的多流格式相同的方式進行儲存。作業系統會載入一個NSS檔案過濾驅動程式，可以在應用程式使用檔案時透明地處理多流格式。當NSS檔案被傳輸到非NTFS格式的磁碟卷上時，檔案內部的多個流將被合併轉換為一個流。[34]

分佈連結跟蹤（DLT）

參見：檔案捷徑

分佈連結跟蹤功能允許應用程式跟蹤被重新命名或者移動到同一電腦、域或工作群組的其它卷中的檔案、捷徑和OLE連結。[35]跟蹤功能由一個系統服務提供，使用儲存在元檔案中的對象識別碼（OID）索引實現。[36]當應用程式請求跟蹤某個檔案或目錄後，跟蹤服務將會建立對象的OID項並指向目標。在一個NTFS v3上執行檔案重新命名、複製或移動操作時，也會同時複製對象的OID，這樣跟蹤服務就可以有效地尋找到目標。

單實例儲存（SIS）

當若干個不同目錄中存有內容相同的檔案時，單實例儲存允許將相同檔案合併到一個單一檔案中，並將所有檔案參照到實際的檔案上。單實例儲存功能包含一個用於管理複製、修改和合併檔案的檔案系統過濾器和一個用於搜尋需要合併的相同檔案的用戶空間服務（「groveler」）。單實例儲存提出時的主要針對目標是遠端安裝伺服器，這些伺服器上往往擁有若干個包含大量相同檔案的安裝鏡像，單實例儲存可以將它們統一起來，因而節省需要佔用的總尺寸。和硬連結不同的一點是，在SIS下，每個檔案在邏輯上仍然是獨立的，更改被合併為單個檔案的任意其中一個檔案都不會影響其它檔案，而是會取消對該檔案的合併並產生一個新的副本。不過新檔案不會立即寫入到硬碟，NTFS使用類似於寫入時複製的技術，在檔案最終需要儲存時才執行複製。[37]

內部實現

Windows Vista系統上的NTFS檔案權限設置對話方塊。

在內部，NTFS使用B+樹索引檔案系統數據。這種數據結構的方式實現比較複雜，但能夠在大多數情況下提高檔案的尋找速度。檔案系統紀錄檔用於確保檔案的元數據完整，不存在孤立的檔案內容。相比於FAT檔案系統，NTFS檔案系統的可靠性更高。[38]

NTFS允許對名稱（包括檔案名稱、流名稱、索引名稱等）使用除了0x0000以外的任意16位元值序列進行編碼。這意味着支援NTFS支援UTF-16碼位，但檔案系統並不會檢查某個UTF-16序列是否有效（也即允許NTFS內部任意16位元整數序列，不受Unicode標準的限制）。

分區引導磁區

NTFS 引導磁區內容
位元組偏移 欄位長度（位元組） 典型值 欄位名 描述
0x00 3 0xEB5290 JMP 指令 用於命令處理器繼續執行引導磁區後的內容
0x03 8 "NTFS    "
單詞「NTFS」，以及後續四個空格（0x20） 		OEM 標識 用於標記當前分區使用NTFS檔案系統
0x0B 2 0x0200 每磁區位元組數 說明每個磁區的位元組數
0x0D 1 0x08 每簇磁區數 說明每個簇包含的磁區數
0x0E 2 0x0000 保留磁區數 被作業系統保留的磁區數，參考文獻中未說明保留磁區的位置
0x10 3 0x000000 未使用 該欄位的內容始終為零
0x13 2 0x0000 NTFS 未使用 該欄位的內容始終為零
0x15 1 0xF8 媒介描述符 參考檔案中未說明詳細資訊
0x16 2 0x0000 未使用Unused 該欄位的內容始終為零
0x18 2 0x003F 每磁軌磁區數 說明每個磁軌的磁區數
0x1A 2 0x00FF 磁頭數 該驅動器包含的讀寫磁頭數
0x1C 4 0x0000003F 隱藏磁區數 隱藏的磁區數目。參考文獻中未說明隱藏磁區位置
0x20 4 0x00000000 未使用 NTFS未使用
0x24 4 0x80008000 未使用 NTFS未使用
0x28 8 0x00000000007FF54A 總磁區數 該分區包含的總磁區數目
0x30 8 0x0000000000000004 $MFT 簇編號 $MFT 所在的簇的編號
0x38 8 0x000000000007FF54 $MFTMirr 簇編號 $MFT鏡像（備份）所在的簇的編號
0x40 1 0xF6 檔案記錄段位元組數 每個檔案記錄段的包含的位元組數目。如果該值為負數，則實際值為 2 的 -value 次冪，例如值 0xF6 表示記錄長度為 2^10（10==-0xf6）
0x41 3 0x000000 未使用 NTFS未使用該欄位
0x44 1 0x01 索引緩衝簇數 每個索引緩衝佔據的簇數目，演算法和檔案記錄段相同
0x45 3 0x000000 未使用 NTFS未使用該欄位
0x48 8 0x1C741BC9741BA514 卷序列數 該分區的唯一隨機編號，用於確保內容一致性
0x50 4 0x00000000 校驗和 表中上述所有專案的校驗和。文獻中未說明校驗演算法
0x54 426 啟動指令碼 用於載入作業系統其它部分的指令碼，該欄位位置正是引導磁區前三個位元組指向的位置
0x01FE 2 0xAA55 磁區結束標記 該欄位用於標記一個正常磁區的結束

[39]

作業系統首先通過0x30位置的8個位元組找到 $MFT 所在的簇編號，然後將其和每簇磁區數（0x0D位置的1位元組）以及每磁區位元組數（0x0B位置的2位元組）相乘，獲得$MFT的位元組偏移量。

主檔案表（MFT）

在NTFS中，所有檔案數據——檔名、建立日期、訪問權限（使用存取控制列表（ACL）實現），以及內容——都作為元數據儲存在主檔案表中。這種抽象的實現方式能夠大大簡化為檔案系統添加功能的成本。例如，Active Directory（活動目錄）服務可以很容易在檔案系統中為檔案添加索引欄位。這種設計方式也使得Everything或者Ultrasearch[40]一類的軟件可以不依賴於Windows Search實現對檔案和資料夾名稱的即時搜尋。

MFT結構支援最小化磁碟碎片的演算法。[41]一個目錄項同時包含「檔名」和「檔案ID」，後者是用於在主檔案表中標識檔案的記錄編號。檔案ID也包含「重用次數」資訊，可用於檢測對檔案的過期參照。這點設計非常類似於Files-11檔案系統的W_FID，和NTFS的其他部分迥然不同。

元檔案

NTFS包含若干用於定義和組織檔案系統的檔案。總體來說，這些檔案中的絕大多數結構和其它用戶檔案類似（只有「$Volume」比較特殊），但不能被檔案系統客戶端直接訪問。這些元檔案為定義檔案、備份檔案系統的關鍵數據、快取檔案系統的更改、管理空閒空間的分配、滿足BIOS的要求、跟蹤壞磁區單元，以及儲存安全資訊和磁碟空間使用情況等等多種不同需求提供支援。

區段編號 檔名 作用
0 $MFT 描述卷上的所有檔案，包括檔名、時間戳、流名稱和數據流所在的簇的編號列表、索引、安全識別碼，以及檔案屬性（如「唯讀」、「壓縮」、「加密」等）。
1 $MFTMirr $MFT的最開始的幾個關鍵項的副本，通常是4項（4KiB）。
2 $LogFile 檔案系統更改的事務紀錄檔，用於保護元數據的穩定性。
3 $Volume 卷的相關資訊，如卷對象識別碼、卷標、檔案系統版本，以及若干卷標誌（包括：「正在載入」、「需要掃描」、「需要調整$LogFile大小」、「在NT4上載入」、「正在更新卷序列號」、「需要升級結構」等）。這些數據不直接在數據流中儲存，而是儲存於特殊的 MFT 屬性中。如果卷對象識別碼存在，則將會在一個 $OJBECT_ID 記錄中；卷標儲存在 $VOLUME_NAME 記錄中；其它數據儲存在 $VOLUME_INFORMATION 記錄中；卷序列號儲存在$Boot檔案中（請參見下文）。
4 $AttrDef 所有NTFS專案使用到的屬性的定義表，包含屬性名稱、屬性編號和屬性描述等。
5 . 根目錄。目錄數據儲存在兩個名稱均為 $I30 的 $INDEX_ROOT 和 $INDEX_ALLOCATIOn 屬性中
6 $Bitmap 一個點陣圖，每一位按順序指示卷上的對應簇正在被使用（1）或空閒（0）。
7 $Boot 卷引導記錄，該檔案始終位於卷的第一個簇，其中包含引導代碼（用於定位並啟動NTLDR/BOOTMGR）、BIOS參數塊（其中包含卷序列號），以及$MFT和$MFTMirr所在的簇編號。
8 $BadClus 包含所有標記為「有壞磁區」的簇的一個檔案。該檔案通常被chkdsk（磁碟掃描）工具使用，用於管理所有簇狀態，記錄壞磁區，以及標記空白簇。該檔案包含兩個數據流（無論卷是否有壞軌）：一個包含所有壞磁區編號的無名稱流（如果卷沒有壞磁區則該流長度為零），以及名稱為$Bad的流，包含所有包含記錄在第一個流中的簇。
9 $Secure 存取控制列表（ACL）資料庫，NTFS將所有ACL資訊集中儲存於該資料庫（而非每個檔案獨立儲存各自的ACL）以節省磁碟佔用並提高執行效率。此部分包含兩個索引，分別是：「$SII」——可能是[來源請求]安全ID索引，以及「$SDH」——安全描述符雜湊。注意大部分ACL列表通常都很長，因此這個部分只是索引，記錄的是實際儲存ACL數據的$SDS流的位置。[1]
10 $UpCase Unicode大寫字母表，用於確保在Win32和DOS命名空間下大小寫不敏感。
11 $Extend 檔案系統目錄，用於包含若干作業系統或其它軟件所需要的擴充數據，如$Quota、$ObjId、$Reparse、$UsnJrnl等。
12 ... 23 保留為 $MFT 擴充項使用。擴充專案是一系列附加MFT記錄，用於描述未在主記錄中包含的屬性。例如，當卷需要磁碟清理，包含太多流，具有長檔名或者非常複雜的安全設定，以及其它特殊情況時，可能會用到保留專案
24 $Extend\$Quota 磁碟限額設置。包含兩個索引根目錄，名稱分別為$O和$Q。
25 $Extend\$ObjId 分佈連結跟蹤數據。包含一個索引根目錄，名稱為$O。
26 $Extend\$Reparse 卷上所有重解析點（如符號連結）數據。包含一個索引根目錄，名稱為$R。
27 ... file.ext 常規檔案系統專案的起始位置。

Windows對這些元檔案的處理方式較為特殊，直接由NTFS.SYS進行處理，因此難以直接檢視，需要使用特殊工具進行提取。從Windows 7開始，NTFS驅動程式完全阻擋了用戶訪問權限，任何嘗試訪問元檔案的請求都會直接進入藍畫面死機介面。微軟「OEM支援工具」中的「nfi.exe（NTFS檔案磁區資訊實用工具）」是一個可檢視這些檔案的工具l.liru，要檢視「$MFT」的內容，只需使用下列命令列：nfi.exe c:\$MFT。另一個繞過作業系統保護限制的方法是使用7-Zip檔案管理器工具並輸入低階NTFS路徑\\.x:\，此時將會出現三個新的資料夾：$extend、$[DELETED]以及[SYSTEM]。這個操作可以用於任何抽取式裝置，但如果需要訪問當前活動分區，則需要進入離線模式（也即WinRE）。

從MFT到屬性、屬性表和流

對於每個MFT記錄所描述的檔案或目錄，都有一個線性存放的流描述符（也即屬性）儲存區，被打包後存放在一個變長記錄（也即屬性表）中，然後使用額外的填充符填充以滿足MFT記錄的1Kib對齊要求。這部分數據完整地描述了和檔案相關聯的所有數據流。注意此處的「流」和檔案數據流不是一個概念，而是所有數據資訊的統稱。

每個流（或稱屬性）本身包含如下數據：類型（內部通常儲存為一個固定長度的整數或者一個描述符，但通常開發應用程式開發時呼叫FileOpen()或者FileCreate() API時會使用等效的識別碼來代表它）、流名稱（可選，注意和檔名沒有任何關係），以及數據（可選，但大部分流具有數據）。對於NTFS而言，檔案的主數據（也即檔案內容）、目錄的索引資訊、檔案的可選數據流、以及檔案的所有屬性，處理方式都是完全相同的，他們都是屬性表中的某個屬性而已。

  • 對於每個MFT中描述的檔案（或非常駐的流描述符儲存區，此概念請參考下文），每種流描述符（使用流類型+流名稱聯合區分）必須唯一。此外，NTFS還對於描述符有一些用於排序的約束要求。
  • NTFS預定義了一種稱為「空流」的類型，用於在流儲存區中表明流描述符的結尾。空流必須是每個儲存區中的最後一個流描述符，所有之後的剩餘空間都將被忽略，只包含填充位元組（用於滿足MFT的記錄尺寸要求或者非常駐流儲存區的簇尺寸要求）。
  • 對於每個MFT記錄，某些類型的流必須存在，例外是整個記錄只有一個空流表示該記錄未使用。
    • 這裏的「某些」具體指的是包含時間戳和其它單位元（Bit）的屬性的「標準屬性」，這種屬性的長度和格式是固定的，這是為了相容DOS或者Windows 95/98管理的FAT/FAT32檔案。
  • 某些類型的流不能包含名稱，必須是匿名的。
    • 這裏的「某些」包括標準屬性、NTFS的「檔名」流，以及「短檔名」流（注意如果該檔案無需考慮對DOS應用程式的相容性，則「短檔名」流並不一定出現）。有些時候檔案也可能只包含「短檔名」而沒有「檔名」，這時候短檔名會代替檔名顯示在檔案總管的「檔名」一欄中。
    • 即使流儲存區中包含有「檔名」流，也並不表示檔案一定會出現在檔案系統中。要顯示檔案，該專案還必須要進入卷上的某個目錄的索引表。注意目錄的索引表中除了記錄該檔案的MFT記錄編號外，也對檔案單獨提供一份MFT記錄、安全描述符、屬性表等，因此理論上單個檔案可以被多個目錄「硬連結」多次，並且在每個目錄中顯示為不同的名稱。
  • 表示檔案數據的預設數據流的流類型為$DATA，該數據流沒有名稱。可選數據流使用同樣的流類型，但必須具有流名稱。
  • 目錄的預設數據流和檔案的情況不同，目錄的數據流（存放檔案的索引表）不是匿名的，NTFS會通過目錄的數據流的名稱（如在NTFS 3以上版本中為「$I30」）來表明目錄索引的格式。

可以使用nfi.exe（NTFS檔案磁區資訊實用工具）檢視任意檔案或者目錄的數據流，這個實用工具目前包含在Microsoft OEM Support Tools中，可以免費發佈。[42]

常駐檔案和非常駐檔案

為了最佳化小數據檔案的資源佔用並降低I/O負荷，在流描述符和檔案數據大小總和不超過單個MFT最大記錄大小時，NTFS會直接將數據放入流描述符區域中（通常情況下，MFT中數據流的內容是實際檔案數據鎖在的簇的列表）。此類直接將數據存入MFT的檔案被稱電腦取證工作者稱為「常駐數據」。常駐檔案允許的數據量受到檔案其它資訊佔用的流描述符大小的影響，通常一個沒有可選數據流、檔名不長且無特殊ACL設置的檔案允許存放700到800個位元組。

  • 某些流描述符（如上文提到的首選檔名、基本檔案屬性，以及下文所述的非常駐流主分配表）必須以常駐形式存在。
  • 啟用NTFS加密的流、稀疏數據流，以及壓縮數據流無法常駐。
  • 非常駐流的分配圖格式和檔案是否為稀疏檔案有關。對目前版本的NTFS而言，如果某個非常駐數據流被轉換為稀疏流，將無法還原為非稀疏格式，因此該檔案將無法重新常駐，除非將流完全截斷並且丟棄整個稀疏分配圖。
  • 如果一個非常駐數據流碎片太多，以至於在MFT記錄中無法放下整個分配圖，則分配圖本身可能也會被存放到一個非常駐流當中，而檔案本身只包含一個小型常駐數據流，其內容是標識非常駐分配圖所在的簇的位置。
  • 如果一個檔案的流太多（包括可選數據流、擴充屬性、安全描述符等），流描述符無法完整放入MFT中，則NTFS也會建立一個非常駐數據流，用於存放必須常駐的流之外的其它流描述，該數據流使用和MFT一樣的格式，但不再有空間尺寸限制。

由於常駐檔案不直接佔據簇（也即基本的「單位配置」），這使得NTFS卷有可能包含比簇數目更多的檔案。例如，一個80GB（74.5GiB）的分區，NTFS可以將其格式化並產生19,543,064個4KiB的簇。除去系統檔案（64MiB紀錄檔檔案，一個2,442,888位元組的點陣圖，以及大約25個簇的固定頭部），還剩餘19,526,158個簇可用於檔案和索引。由於每個簇有4個MFT記錄，因此卷理論上可以包含將近4×19,526,158 = 78,104,632個常駐檔案。

機會鎖

機會鎖（Oplock）允許網絡客戶端改變對檔案或數據流的快取策略，以便於增強效能或降低網絡佔用。[43]機會鎖應用到檔案某個打開的流上，不影響同一個檔案的其它流。

機會鎖可以用於在後台透明訪問檔案。如果沒有其它行程訪問伺服器檔案，網絡客戶端可以避免向檔案寫入數據；而如果沒有其他行程正在寫入數據，客戶端可以快取即將讀取的數據。

Windows支援四種不同類型的機會鎖：

  • 等級2（共用）：多個讀取，不可寫入（也即讀快取）。
  • 等級1（獨佔）：任意緩衝方式的獨佔訪問（也即讀寫快取）。
  • 批次鎖（也是獨佔的）：在伺服器上打開流，在客戶端關閉流（讀、寫和控制代碼快取）。
  • 過濾鎖（也是獨佔的）：當其它程式嘗試訪問流時，應用程式和系統過濾器可以放棄該鎖（讀寫快取，從Windows 2000開始受支援）

在Windows 7和Windows Server 2008 R2系統中，機會鎖得到增強，支援每個客戶端使用獨立的機會鎖鍵。[44]

時間

Windows NT和後續產品使用UTC作為內部時間戳，並在顯示時進行適當的轉換。也就是說，NTFS時間戳使用UTC模式。

由於歷史原因，不支援NTFS的Windows使用本地時區作為時間戳，而目前版本的Windows對非NTFS分區也是用此方式進行處理。這意味着當檔案在NTFS和非NTFS分區間進行移動時，作業系統需要即時轉換時間戳。如果某些檔案移動時處於夏令時，而某些檔案處於標準時間，則可能移動後的時間可能會產生歧義，特別是當執行時間正好在時制轉換前後時，用戶可能會看到一小時的時間差。基於不同地區的不同夏令時規則，在任意12個月中，可能會產生最多4個小時的永久時間戳錯誤。[45]


互操作性

NTFS具體的內部實現細節屬於商業秘密，這給第三方開發者製作NTFS檔案系統處理程式帶來很大的困難。

Microsoft Windows

儘管絕大多數NTFS版本的絕大部分都完全向前以及向後相容，但在舊版本的Microsoft Windows載入新版本的NTFS卷仍然會產生不少技術問題。這種問題往往來自於同一台電腦的多重新啟動動功能，或者使用流動硬碟裝置傳輸檔案。

例如，在不支援的作業系統上嘗試使用帶有「先前版本」（嚴格的說稱為卷影副本）的NTFS分區，會導致先前版本數據遺失。[46]

Windows提供了一個命令列工具「convert.exe」可用於將部分檔案系統轉換為NTFS，包括HPFS（僅在Windows NT 3.1、3.5和3.51中受支援）、FAT16和FAT32（在Windows 2000及後續版本中受支援）。

Mac OS X

Mac OS X 10.3及後續版本包含對NTFS格式分區的唯讀支援。基於GPL授權的NTFS-3G也可以通過用戶空間檔案系統在Mac OS X上使用並讀寫NTFS分區。NTFS-3G的開發團隊還提供一個效能更好的商業版本，名稱為「Tuxera NTFS for Mac」。[47] Paragon Software Group也出售可執行讀寫操作的驅動程式，名稱為「NTFS for Mac OS X」，[48]部分希捷（Seagate）硬碟包含該組件。[49]Mac OS X 10.6和後續版本中包含有本機NTFS的寫入支援，預設情況下此功能未啟用，可以通過特定方法打開。但有用戶報告此功能不穩定並會導致內核錯誤，可能這也是該功能未啟動或者被宣告的原因之一。[50][51]

Linux

完整並安全的對NTFS的讀寫功能由NTFS-3G 驅動程式提供。該驅動程式包含在絕大多數Linux發行版中。同時也存在過時的，大部分僅唯讀的解決方案：

  • Linux內核2.2：從版本2.2.0開始，可以讀取NTFS分區。
  • Linux內核2.6：包含一個由Anton Altaparmakov（來自劍橋大學）和Richard Russon編寫的驅動程式，該驅動程式支援讀取檔案以及在部分情況下的覆寫檔案和調整檔案大小。
  • NTFSMount：使用ntfsmount可以通過一個用戶級驅動程式對檔案和目錄進行有限的讀寫操作。[52]
  • Tuxera NTFS：高效能可讀寫商業內核驅動，主要是針對嵌入式裝置，他還開發了開源的NTFS-3G驅動。
  • NTFS for Linux：由Paragon Software Group提供的對NTFS提供完整讀寫支援的商用驅動程式，電腦版可免費下載，嵌入式Linux版本則需要收費。
  • Captive NTFS（已停止維護）：一個使用Windows自身的驅動程式「ntfs.sys」並進行簡單封裝的驅動程式。

請注意，上面所有三個用戶級別驅動程式（NTFSMount、NTFS-3G以及Captive NTFS）都基於用戶空間檔案系統（FUSE）實現的，該系統是一個用於在用戶空間和內核代碼間通訊以取得或儲存數據的Linux內核模組。上面所有的驅動程式（除了Tuxera NTFS和Paragon NTFS for Linux）都是以GPL的方式開源的。由於NTFS內部結構非常複雜，內建的2.6.14內核驅動程式和FUSE都不允許修改被認為是不安全的卷，以避免發生數據遺失。

其他

eComStation和FreeBSD都提供對NTFS的唯讀訪問支援（eComStation有一個測試版本的驅動程式允許寫入／刪除操作，但通常認為該驅動程式還不安全）。BeOS有一個基於NTFS-3G的第三方工具，允許完整的NTFS讀寫操作。除了Linux，NTFS-3G也能工作在Mac OS X、FreeBSD、NetBSD、Solaris以及Haiku上。同時，也有一個稱為「NTFS4DOS」的商用驅動程式允許在DOS下進行讀寫。[53] Ahead Software曾經在2002至2004年間開發了一個名為「NTFSREAD」的驅動程式（版本1.200），可用於DR-DOS，並曾包含在他們的Nero Burning ROM軟件中。OpenBSD在2011年5月1日發佈的4.9版本中提供了針對i386和amd64體系結構的NTFS唯讀支援。[54] Google開發的Chrome OS作業系統也支援NTFS[55]。

調整大小

有許多第三方工具可以安全地重新調整NTFS分區的大小。在Windows Vista中，Microsoft添加收縮和擴充分區的功能，但該功能非常有限，因為該功能無法整理頁面檔案碎片或者標記為不抽取式的檔案，因此限制對分區的收縮能力。取消頁面檔案重新啟動或使用第三方的工具進行磁碟重組也許能改善收縮效果。

另請參閱

參考文獻

  1. ^ 1.0 1.1 1.2 1.3 1.4 Mark Russinovich. Inside Win2K NTFS, Part 1. Microsoft Developer Network. [2008-04-18]. （原始內容存檔於2008-04-13）.  參照錯誤：帶有name屬性「insidewin2kntfs」的<ref>標籤用不同內容定義了多次
  2. ^ 2.0 2.1 2.2 2.3 2.4 Microsoft Corporation. How NTFS Works. [2008-01-27]. （原始內容存檔於2011-08-24）. 
  3. ^ 3.0 3.1 Richard Russon and Yuval Fledel. NTFS Documentation. [2007-07-01]. （原始內容存檔於2006-02-13）. 
  4. ^ JasonGerend. NTFS 概述. learn.microsoft.com. 2023-03-28 [2024-05-23] （中文（中國大陸））. 
  5. ^ 5.0 5.1 Custer, Helen. Inside the Windows NT File System. Microsoft corporation. 2020. ISBN 978-1-55615-660-1. 
  6. ^ Kozierok, Charles M. Overview and History of NTFS. PCGuide. April 17, 2001 [2008-10-31]. （原始內容存檔於2010-01-02）. 
  7. ^ Recovering Windows NT After a Boot Failure on an NTFS Drive. Microsoft. 2006-11-1-01 [2008-10-31]. （原始內容存檔於2012-10-24）. 
  8. ^ New Capabilities and Features of the NTFS 3.1 File System. Microsoft. 2007-12-01 [2011-04-01]. （原始內容存檔於2010-09-14）. 
  9. ^ Change Journals (Windows). MSDN. [2010-04-16]. （原始內容存檔於2011-01-17）. 
  10. ^ Creating, Modifying, and Deleting a Change Journal (Windows). MSDN. [2010-04-16]. [永久失效連結]
  11. ^ MS Windows NT Workstation 4.0 Resource Guide, "POSIX Compatibility （頁面存檔備份，存於互聯網檔案館）"
  12. ^ MSDN - CreateHardLink function. [14 January 2016]. （原始內容存檔於2016-09-10）. 
  13. ^ Russinovich, Mark E.; Solomon, David A.; Ionescu, Alex. File Systems. Windows Internals 5th. Microsoft Press. 2009: 921. ISBN 978-0-7356-2530-3. 一個使用多數據流的Windows組件例子是附件執行服務[...]，根據檔案所下載位置的所屬區域不同[...]，Windows檔案總管可能會警告用戶 
  14. ^ Sysinternals Streams v1.56. [2011-04-01]. （原始內容存檔於2011-03-18）. 
  15. ^ FileSystem Provider. Microsoft. 9 August 2012 [23 January 2015]. （原始內容存檔於2015年1月23日）. 
  16. ^ Malware utilising Alternate Data Streams? （頁面存檔備份，存於互聯網檔案館）, AusCERT Web Log, 21 August 2007
  17. ^ File Compression and Decompression. MSDN Platform SDK: File Systems. [2005-08-18]. （原始內容存檔於2019-10-18）. 
  18. ^ The Default Cluster Size for the NTFS and FAT File Systems. Microsoft. January 31, 2002 [2012-01-10]. （原始內容存檔於2012-01-30）. 
  19. ^ Understanding NTFS Compression. [2011-03-16]. （原始內容存檔於2011-06-29）. 
  20. ^ Shrinking the gap: carving NTFS-compressed files. [2011-05-29]. （原始內容存檔於2011-10-07）. 
  21. ^ Middleton, Dennis. Understanding NTFS Compression. Ntdebugging Blog. Microsoft. 20 May 2008 [2011-04-01]. （原始內容存檔於2011-06-29）. 
  22. ^ How NTFS Works. 2003-03-28 [2011-10-24]. （原始內容存檔於2016-07-30）. 
  23. ^ Should You Compress Data On Your SSD?. 2011-12-01 [2013-04-05]. （原始內容存檔於2023-06-01）. 
  24. ^ Disk Concepts and Troubleshooting. Microsoft. [2012-03-26]. （原始內容存檔於2012-04-20）. 
  25. ^ Read-Only Filegroups and Compression. SQL Server 2008 Books Online (November 2009). [2010-04-20]. （原始內容存檔於2010-03-06）. 
  26. ^ "Best practices for NTFS compression in Windows （頁面存檔備份，存於互聯網檔案館）." Microsoft Knowledge Base. Retrieved on 2005-08-18.
  27. ^ Daily, Sean. Optimizing Disks. IDG books. January 1998 [2007-12-17]. （原始內容存檔於2007-12-17）. 
  28. ^ Sparse File Errors: 1450 or 665 due to file fragmentation: Fixes and Workarounds （頁面存檔備份，存於互聯網檔案館）, Microsoft Customer Service and Support (CSS) SQL Server Engineers Blog, March 4, 2009
  29. ^ Sparse Files. MSDN Platform SDK: File Systems. [2005-05-22]. （原始內容存檔於2019-10-18）. 
  30. ^ Sparse FIles and Disk Quotas. Win32 and COM Development: File Systems. [2007-12-05]. （原始內容存檔於2008-02-24）. 
  31. ^ Transactional NTFS. MSDN. [2007-02-02]. （原始內容存檔於2008-10-11）. 
  32. ^ How EFS Works （頁面存檔備份，存於互聯網檔案館）, Microsoft Windows 2000 Resource Kit
  33. ^ Symbolic Links (Windows). MSDN. [2017-05-28]. （原始內容存檔於2016-02-06）. 
  34. ^ John Saville, "What is Native Structured Storage? （頁面存檔備份，存於互聯網檔案館）"
  35. ^ 存档副本. [2013-07-25]. （原始內容存檔於2016-03-12）. 
  36. ^ http://technet.microsoft.com/en-us/library/cc736811（WS.10）.aspx[永久失效連結]
  37. ^ Single Instance Storage in Windows 2000 (PDF). Microsoft Research and Balder Technology Group. [2008-10-31]. （原始內容存檔 (PDF)於2008-10-29）. 
  38. ^ "Microsoft TechNet Resource Kit （頁面存檔備份，存於互聯網檔案館）"
  39. ^ NTFS Partition Boot Sector （頁面存檔備份，存於互聯網檔案館） Information on structure of the boot sector.
  40. ^ UltraSearch v1.7 – Freeware for Ultra-Fast File Search. [2013-10-17]. （原始內容存檔於2013-04-25）. 
  41. ^ Master File Table. MSDN. July 2, 2012. [永久失效連結]
  42. ^ OEM Support Tools Phase 3 Service Release 2 Availability. Microsoft Corporation. 2007-02-21 [2010-06-16]. （原始內容存檔於2015-02-23）. Windows NT File System (NTFS) File Sector Information Utility [...] A tool used to dump information about an NTFS volume 
  43. ^ 存档副本. [2013-07-25]. （原始內容存檔於2010-08-23）. 
  44. ^ http://technet.microsoft.com/en-us/library/ff383236（WS.10）.aspx[永久失效連結]
  45. ^ "Beating the Daylight Saving Time bug and getting correct file modification times （頁面存檔備份，存於互聯網檔案館）" The Code Project
  46. ^ cfsbloggers. How restore points and other recovery features in Windows Vista are affected when dual-booting with Windows XP. The Filing Cabinet. July 14, 2006 [2007-03-21]. （原始內容存檔於2006-07-18）. 
  47. ^ Tuxera NTFS for Mac. Tuxera. August 30, 2011 [September 20, 2011]. （原始內容存檔於2013-10-17）. 
  48. ^ NTFS for Mac OS X, communication channel between Mac OS X and Windows. Paragon Software Group. [September 20, 2011]. （原始內容存檔於2013-10-17）. 
  49. ^ Seagate Read/Write NTFS driver for Mac OS X. [2013-10-17]. （原始內容存檔於2011-02-10）. 
  50. ^ Alvares, Milind. Snow Leopard's hidden NTFS read/write support. 2009-10-02 [18 September 2010]. （原始內容存檔於2010年8月10日）. 
  51. ^ How to Write to NTFS Drives on a Mac. [2018-04-05]. （原始內容存檔於2018-04-05）. 
  52. ^ "ntfsmount wiki page on linux-ntfs.org （頁面存檔備份，存於互聯網檔案館）"
  53. ^ Recovery information. [2008-10-31]. （原始內容存檔於2008-11-09）. 
  54. ^ 存档副本. [2013-10-17]. （原始內容存檔於2013-10-17）. 
  55. ^ Chromebook 支援的檔案類型和外接裝置. [2021-05-04]. （原始內容存檔於2021-06-08）. 

外部連結

取自 "https://zh.wikipedia.org/w/index.php?title=NTFS&oldid=82752895"