Talk:NTFS

Versions

The text now reads:

NTFS has five versions:

   * v1.0
   * v1.1
   * v1.2 found in NT 3.51 and NT 4
   * v3.0 found in Windows 2000
   * v3.1 found in Windows XP, Windows Server 2003, and Windows Vista

These final three versions are sometimes referred to as v5.0, v5.1, and v6.0, after the version of Windows NT with which they ship. Each newer version added extra features, for example Windows 2000 introduced quotas while Windows Vista introduced Transactional NTFS, NTFS symbolic links, and self-healing functionality.[7]

"These final three versions" can't be right.

a) That would mean that v.1.2 is sometimes referred to as v.5.0 after NT 4.

b) If, indeed, as the text states, v3.1 is found in XP, 2003, and Vista, then we are saying that v3.1 is sometimes referred to as v5.1 after XP and 2003 and that v3.1 is also sometimes referred to as v6.0 after Vista.

That could be. I don't have Vista, so can't check what version of NTFS is shipped with Vista. A bit of web surfing and searching turned up no answer. (Above there is mention of a reference that indicates Vista uses NTFS v3.1; but at this time the response of the referenced server is too slow to please Firefox.)

    --Joaquin  —Preceding comment was added at 01:00, 21 November 2007 (UTC) 

The comment was corrupted by some intermediate change. A quick check back to January finds this wording:

  * v3.1 found in Windows XP, Windows Server 2003, and in current pre-release versions of Windows Vista
  These final three versions are sometimes referred to as v4.0, v5.0, and v5.1, after the version of Windows
  with which they ship. Each newer version added extra features, for example Windows 2000 introduced quotas.

...so there's more to research before fixing the text Tedickey (talk) 01:11, 21 November 2007 (UTC)

I just ran fsutil on my Vista Ultimate laptop, and it reported NTFS v3.1:

C:\Windows\system32>ver

Microsoft Windows [Version 6.0.6000]

C:\Windows\system32>fsutil fsinfo ntfsinfo C:
NTFS Volume Serial Number :       0xde7067487067270d
Version :                         3.1
...

Note that fsutil requires admin rights, so in Vista you need to load cmd.exe as Administrator. If you have a shortcut to cmd.exe, right-click on it and choose Run As Administrator. Or do a search for cmd.exe, and run it as an admin. I couldn't get the oft-quoted Control-Shift-Enter trick to work in the release version of Vista. — EagleOne\^Talk 07:08, 31 December 2007 (UTC)

What means "occasionally" or "sometimes referred" for NTFS 5.0? Microsoft introduced NTFS 5.0 with Windows 2000 (NT 5). Background: http://www.microsoft.com/msj/1198/ntfs/ntfs.aspx , http://www.pcguide.com/ref/hdd/file/ntfs/verNTFS50-c.html (Microsofts offical wording: i.e. http://support.microsoft.com/kb/186750/en-us) 85.178.82.64 (talk) 08:07, 13 September 2008 (UTC)

Occasionally means that different people call it different names. Examination of the file system record which contains the major and minor version (file id 3 named \$Volume, record type 0x70 ($VOLUME_INFORMATION), is a sixteen byte record ("attribute") where the byte at offset 8 contains the major version and offset 9 is a byte with the minor version. I have researched this by installing various windows versions, formatting volumes, and running a program which displays these bytes:

NTFS major	NTFS minor	microsoft marketing product name	OS internal version number
1	0	NT 3.1	3.10 beta, as least as late as build 340
1	1	NT 3.1	3.10 beta, as least as early as build 404
1	2	NT 3.5 and NT 3.51	3.50 and 3.51
1	2	NT 4.0	4.0
3	0	Windows 2000	5.0
3	1	Windows XP	5.1 and 5.2
3	1	Windows Server 2003	5.2
3	1	Windows Vista	6.0
3	1	Windows Server 2008	6.0

There is no NTFS version 5.0! But those with an OS-centric view naturally assume that NT 5.0 (aka Win2K) must create NTFS 5.0 volumes. Some highly respected people do it, but that isn't an excuse for not trying to get it right. —EncMstr (talk) 20:44, 13 September 2008 (UTC)

Please ignore WP:NOR for a second and put this clear table in the article, at the moment the text is slightly confusing. And while at it remove my "fact"-tag if you are sure that the $boot file has size 8192 — but my own original research tends more towards "one $boot cluster", e.g., I found the backup always in the last cluster for cluster size 8 (= 4096 bytes for sector size 512). –82.113.103.164 (talk) 16:37, 20 August 2011 (UTC)

Further to your research above, Windows NT 3.1 - when released - actually shipped with NTFS 1.1. NTFS 1.0 was only ever included in beta releases and never publicly shipped. I tested 7 different beta builds of Windows NT 3.1, and some time between build 340 and build 404, the NTFS version number (as reported in the VOLUME_INFORMATION attribute of the $Volume file) changed from 1.0 to 1.1. Djhayman (talk) 06:20, 13 July 2019 (UTC)

Intellectual property restrictions?

Years ago some Linux distros refused to include NTFS code due to IP issues. Today the consensus seems to be, that there are no IP restrictions on NTFS implementations. Can someone clear this up? Were there IP issues and they expired? --Xerces8 (talk) 19:10, 22 February 2010 (UTC)

[1] from a vendor selling an NTFS drivers says there are no known patents and Microsoft has never said there were any patents. This doesn't of course mean there are no patents but although I can find a lot of talk about patent risks I can't find anyone who's actually identified a patent (but didn't look that hard). Microsoft has enforced patents involving File Allocation Table recently, it would be interesting to note what the situation there was like. Had Microsoft ever said anything about having patents and had others ever identified the patents and how long ago? Nil Einne (talk) 13:17, 29 April 2011 (UTC)

This might be a reference to 'short filename' (8+3) support, where a 'long' file name is transformed into a short one. A method for doing this was introduced with VFAT (and so Windows 95). Microsoft had a number of patents related to long/short file names, but as far as I can find they lapsed in 2013 or thereabouts. See http://en.wiki.x.io/wiki/File_Allocation_Table, section on Patents for details. Athulin (talk) 08:15, 6 October 2024 (UTC)

data deduplication?

I marked "data deduplication" as in need of a citation. I am not aware that NTFS provides this feature. In case it is meant to refer to "Single Instance Storage", this is not an NTFS feature, but a service provided by some Windows OS's (mostly server versions). If data deduplication were truly a NTFS feature, it would be available regardless of the OS, but this turns out not to be true as e.g. Windows XP is based on NTFS but does not provide data deduplication natively. boarders paradise (talk) 07:41, 26 February 2011 (UTC)

wrong link

Wrong link #24: http://www.windowsitlibrary.com/Content/435/07/8.html -- redirects to bookstore http://www.left-brain.com/ —Preceding unsigned comment added by 212.192.248.201 (talk) 12:59, 10 March 2011 (UTC)

Maximum clusters

However, the maximum NTFS volume size as implemented in Windows XP Professional is 232−1 clusters

This is confusing. Does it mean the maximum in newer versions of Windows is higher or is it the maximum was lower before Windows XP Professional but is the same until Windows 7 or has it always been the same but it is outdated/using an outdated ref Nil Einne (talk) 13:07, 29 April 2011 (UTC)

Should be 2³²-1 clusters, but yes, that is correct. In 2003, there were no disks (though there were a few rare disk storage controllers) with more than 32 bit LBA, so presumably the raw disk driver in XP did not address that many blocks. Lacking that support, there was no need for the NTFS driver to manage cluster numbers with more than 32 bits, a considerable simplification at the time before 64-bit CPUs. The data structure containing cluster numbers was architected at inception for values up to 15 bytes, 120-bit cluster numbers! Probably those aren't internally supported either now, and won't be for a long time. —EncMstr (talk) 17:49, 29 April 2011 (UTC)

Linux drivers disallow unsafe volume changes, to avoid corruption

Due to the complexity of internal NTFS structures, both the built-in 2.6.14 kernel driver and the FUSE drivers disallow changes to the volume that are considered unsafe, to avoid corruption.

I'm trying to grasp what useful information this gives (from the end of the section about the Linux NTFS drivers). As a programmer this is about like reading a section about a memory manager that says it doesn't allow freeing a block twice, to avoid corruption. Is it that these "unsafe" changes are ones that are genuinely useful in some circumstances and don't cause corruption, but cause corruption in others, and are thus disallowed (even though functionality is reduced)? 72.48.75.131 (talk) 05:21, 19 November 2011 (UTC)

File:NTPermissions.png Nominated for speedy Deletion

An image used in this article, File:NTPermissions.png, has been nominated for speedy deletion for the following reason: Wikipedia files with no non-free use rationale as of 3 December 2011 What should I do? Don't panic; you should have time to contest the deletion (although please review deletion guidelines before doing so). The best way to contest this form of deletion is by posting on the image talk page. If the image is non-free then you may need to provide a fair use rationale If the image isn't freely licensed and there is no fair use rationale, then it cannot be uploaded or used. If the image has already been deleted you may want to try Deletion Review This notification is provided by a Bot --CommonsNotificationBot (talk) 09:58, 3 December 2011 (UTC)

Xbox 360 incompatability

Would it be suitable to add something about Microsofts Xbox 360 not supporting NTFS despite both being Microsoft creations? — Preceding unsigned comment added by 86.164.199.151 (talk) 16:45, 26 December 2011 (UTC)

I don't see why. Lots of of other MS stuff doesn't have NTFS either so why just mention the Xbox? HumphreyW (talk) 16:53, 26 December 2011 (UTC)

I was unaware that a lot of other stuff didn't support it. I thought it was just the xbox. My apologies. — Preceding unsigned comment added by 86.164.199.151 (talk) 17:40, 26 December 2011 (UTC)

File compression

The section about file compression currently states as follows:

Compressing system files used at bootup like drivers, NTLDR, winload.exe, or BOOTMGR may prevent the system from booting correctly.

It cites a TechNet article regarding troubleshooting disk problems on Windows 2000. The page only contains a single reference to compression, which is the error message "NTLDR is compressed."

Why does the article make the assumption that compressing system boot files may cause trouble during bootup? As a test, I fully applied NTFS compression on my Windows 7 x64 system drive (after making a backup). I have since been using it daily, without any issue, for a full two weeks. Initially there was some slowdown during the startup process, but even that seems to have sorted itself out -- presumably by the boot optimizer.

As such, I'm recommending this line be updated or dropped from the article until a more suitable citation can be provided. 142.23.94.224 (talk) 17:58, 13 April 2012 (UTC)

Since XP SP2, Windows has been increasingly more resistent to changes to—even simple viewing of—important system files. I am pretty sure that when you thought you compressed NTLDR and the others, it just ignored it since they cannot be compressed and be functional. The BIOS, first, and second stage boot loaders do not understand file compression. I have not inspected a Win7 volume in great detail, but the NTFS architecture must be basically unchanged since my NTFS forensic analysis software (which I wrote for XP) still work.

More useful changes to that sentence would be along the lines of (those files) cannot be compressed on later Windows versions, or compressing them will prevent booting. —EncMstr (talk) 05:33, 14 April 2012 (UTC)

I believe what you wrote to be true for Windows XP, however Windows 7 does not use NTLDR and it's first stage boot loader does appear to understand NTFS compression. You're right that Windows 7 does not allow you to compress certain system files, however booting to the Recovery Console does in fact allow you to run the Compact console utility against the entire drive's contents.

Rather than cast assumptions as fact, I recommend you try this for yourself in a VM with an evaluation version of Windows 7 or Server 2008 R2. A simple trial install, followed by running COMPACT /C /S /A X:\ in the Recovery Console Command Prompt will be sufficient. 50.92.82.109 (talk) 05:06, 23 April 2012 (UTC)

Re. Microsoft's advice to not compress files larger than 30MB, I think that may be based on the days when 32MB RAM was considered "large". I did a test to get empirical data, filling a file with the repeated string "[0-9][A-Z]", until I got a file around 1.1GB, taking 148MB on disk (approx 1:7.6 compression ratio). Step 1 after employing NTFS compression is to always defrag such a file (as NTFS usually fragments them something horribly). However, after defragmentation, testing using a spinning platter disk displays a performance increase pretty much matching compression ratio (with a small overhead added for decompression) for this highly compressible data (cache was thoroughly flushed first, else the performance on reading the compressed file was over 3.5GB/s on this system). Test was repeated on an SSD (on S-ATA 6Gbps) with close to 0.5GB/s raw read performance, and here the numbers changed a bit (most likely due to how NTFS reads compressed data - in chunks of however much 16 compressed 4KB blocks compresses to). Here the compressed data was actually slower to sequentially read (the first time) than from the spinning platter disk, even slower than raw sequential read of the uncompressed data (that's was read with batch-sizes more suitable to fit an SSD). As a general rule-of-thumb I'd take anything Microsoft says with a grain of salt. When it comes to filesystems that may become more than a pinch. Depending on scenario, you can get a quite significant performance increase by employing compression, so long as the data is 1) read-only, and 2) the disk serving the data is slower at delivering data than "some threshold". For files written to, however, NTFS compression should still be avoided (in no small part due to the inherent fragmentation NTFS creates) - no matter the size of the data. 87.227.18.143 (talk) 15:17, 19 November 2012 (UTC)

"If the compression reduces 64 kB of data to 60 kB or less, ..." I question this. I believe it's rather "If the compression reduces a compression unit (16 clusters) by one cluster or more, ...". 83.252.253.240 (talk) 00:16, 10 February 2016 (UTC)

What is the difference? 4 KiB is one cluster. I have never attempted to designed files as compressed on anything other than a 4 KiB cluster size volume. Perhaps with 2 KiB there be something interestingly different? —EncMstr (talk) 06:23, 10 February 2016 (UTC)

New compression methods in Windows 10

With windows 10 (unknown what build introduced it), it's now possible to select between 4 compression levels/algorithms. The change has not made it to the GUI (and may never do), but compact.exe - the command-line program used to modify NTFS per-file compression since NT 3.51 - has now gotten some new switches. "/EXE" (totally misnamed) can be used as /EXE:XPRESS4K (default since NT 3.51), /EXE:XPRESS8K, /EXE:XPRESS16K, and finally the most interesting /EXE:LZX (most compression).

The reason I added this in the Talk section is I have not tested compatibility of these new compression "modes" with earlier versions of Windows, which is something I feel is required to verify, but found it to be a such a noteworthy improvement it deserved to be documented. If an editor gets a chance to test it, please add the info to the page.

(additionally, this is what Microsoft use in Windows 10 for the "Compact OS", but this fact probably belongs in a different article). 83.252.234.134 (talk) 17:44, 6 December 2016 (UTC)

I have now found an external source of information, https://github.com/ebiggers/ntfs-3g-system-compression, stating "It is not built directly into NTFS but rather is implemented using reparse points.". If this information is correct (and I see no reason it would be incorrect), it is not NTFS data compression as such, but reparse-tag handler(s). This makes it a bit harder to categorize. 83.252.234.134 (talk) 16:50, 8 December 2016 (UTC)

And now checking with a earlier Windows system, it's verified that this data is compressed and stored in an alternate data stream named "WofCompressedData". 83.252.234.134 (talk) 18:15, 8 December 2016 (UTC)

use of non-RS

Per WP:RS, "Reliable sources may be published materials with a reliable publication process, authors who are regarded as authoritative in relation to the subject, or both." This is an example of a source lacking either attribute TEDickey (talk) 01:22, 24 May 2012 (UTC)

The file system is proprietary, undocumented at the raw bytes level, and subject to change - even within Service Packs of the same OS version.

Non-RS Reference

I concur, and have moved the phrase to the talkquote box above. I kept the word proprietary, because that is certainly verifiable. As for "undocumented at the raw bytes level", well, that's pretty much the layman's definition of "proprietary", yes? Finally, "subject to change - even within Service Packs of the same OS version", well, I would hope so... it's called a "hotfix", and that's hardly notable, (per WP:NOTE), especially for an article lead section. Groll†ech (talk) 14:31, 25 May 2012 (UTC)

Folders ending with a . (dot)

Back from the archives, now with an answer:

I use Linux as my main OS and use the NTFS-3G-driver to read and write NTFS-formatted partitions when I need to. When I create a folder ending with a . (dot) in Linux, which works fine, a computer running windows won't open them (tested with Windows 2000, Windows XP and Windows Vista). I don't see that limitation in the article. Can someone please confirm this and add it to the article? --79.212.138.66 (talk) 12:03, 14 April 2010 (UTC)

Answer is here: http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx meaning that the file system supports it but "the Windows shell and user interface does not" — Preceding unsigned comment added by 193.175.21.66 (talk) 13:57, 9 January 2013 (UTC)

Speculative interpretation of commit messages

That is, WP:CRYSTAL. Claiming that something will happen, when it is untested, unannounced, etc., matches the edits made. TEDickey (talk) 01:12, 8 November 2013 (UTC)

Partitions on an MBR formatted disk can be greater than 2TB.

Western Digital and Toshiba on at least some of their 3TB external drives will use logical sector sizes of 4KB for a partition and format it as NTFS, this allows a 3TB HD with a single NTFS formatted partition with an MBR layout to exist and operate on XP. Microsofts tools simply do not allow creating this type of setup. 70.125.54.27 (talk) 00:59, 2 March 2014 (UTC)

Since when does FAT support Alternate Data Streams?

From the article:

Alternate streams are not listed in Windows Explorer, and their size is not included in the file's size. Only the first stream is preserved when a file is copied to a FAT-formatted USB drive, is attached to an e-mail, or is uploaded to a website, so using alternate streams for critical data may cause problems.

Neither FAT32 nor exFAT support ADS, so how can the above statement be true about the first ADS stream being preserved on FAT drives? As far as websites go, they may be running on a variety of file systems that have no ADS support, so I don't see how such a blanket statement can be made either. This whole section seems to be ridden with factual errors and needs to be rewritten by someone knowledgeable. — Preceding unsigned comment added by 120.56.234.98 (talk) 16:35, 9 December 2014 (UTC)

I believe the statement is true: one of the streams is "preserved" in the sense that its full content is what is copied to FAT; all other streams are ignored. The FAT file does not in any way preserve the name of the stream (unless it is the unnamed stream). I am not sure of the exact behavior of Explorer: whether it choose the "first" stream, or only the unnamed stream. Probably the sentence can be made clearer. —EncMstr (talk) 17:12, 9 December 2014 (UTC)

Hi. First stream is not any of the alternative streams. That's why it is called first and they are called "alternative". Best regards, Codename Lisa (talk) 12:16, 12 December 2014 (UTC)

So, if a file has no unnamed stream, does Explorer, etc. take the lexigraphically lowest named stream? —EncMstr (talk) 16:28, 12 December 2014 (UTC)

Every file, without exception, has a first, unnamed, primary stream, even if it means that stream is empty. That's mandatory. (Stream name must not be confused with file name.) Anyway, I clarified the sentence. Best regards, Codename Lisa (talk) 19:18, 13 December 2014 (UTC)

Well, no. It is easy to create a file with no unnamed stream:

C:\> echo somedata > newfile.tmp:streamname

Using tools which display an MFT's attributes, it is easy to see that this works. If any tool is indicating that there is an unnamed stream in such a case, it must be because it assumes there is always an unnamed stream, not because there is one. —EncMstr (talk) 22:09, 13 December 2014 (UTC)

Actually, in doing so, you created a zero-byte unnamed stream, the access to which never fails. Best regards, Codename Lisa (talk) 23:39, 13 December 2014 (UTC)

I take it back: you are correct. Either the NTFS driver added a zero length unnamed stream, or the echo command did. —EncMstr (talk) 09:26, 14 December 2014 (UTC)

References

Master File Table link points to nowhere.

At MFT disambiguation page there is a link to: Master File Table which points to Master File Table, but it doesn't work, so user looking for appropriate topic can't find it. Please fix it. — Preceding unsigned comment added by Kenorb (talk • contribs) 10:34, 21 September 2015 (UTC)

Update: Ok, I've check and it actually works (before it didn't redirect it properly). — Preceding unsigned comment added by Kenorb (talk • contribs) 10:40, 21 September 2015 (UTC)

Unintelligible contributions

Hi

User:Cquarksnow has made two unintelligible contributions on 02:58, 14 February 2016 (UTC). (Hi, Cquarksnow. Are you reading this?) Can anyone please review and verify the issue?

Pinging potential editors with understanding: Jeh, Dsimic

Best regards,
Codename Lisa (talk) 16:27, 14 February 2016 (UTC)

They're intelligible, but essentially editorialization (not encyclopedic). If he does that often, then you can decide how much of a nuisance it is. TEDickey (talk) 16:57, 14 February 2016 (UTC)

@Tedickey: Hi. I need to decide whether to revert or to improve. I'd be grateful if you can tell me briefly what you perceive from it. Also, what do you suggest?

Best regards,

Codename Lisa (talk) 17:19, 14 February 2016 (UTC)

The editor made 2 related comments on compatibility of NTFS which could be reduced to a single sentence (preferably with a second source) pointing out that using a volume on Windows 10 forces it to be upgraded, and that the volume is less than useful thereafter on a Windows 7 machine. The same happened going from Windows 2000 to Windows XP (I recall), and probably happened more than that. Unless someone worked to collect the examples (suitably sourced), the mention of Windows 10 vs Windows 7 is just an incidental comment of only current interest. TEDickey (talk) 17:37, 14 February 2016 (UTC)

Hello! Responding to a ping, I have to point out that I'm no expert when it comes to Windows technologies. However, silent in-place upgrades of filesystem on-disk data have been around, even in backward-incompatible fashion, for example in Linux kernel's ext2/3 code (see also this document). After having a look at the description of NTFS upgrades in Windows 8, I'd say that the description of different NTFS versions introduced by Cquarksnow is fine, but the part about automated filesystem checks is clearly an original research (and maybe leaning slightly toward a how-to) that clearly doesn't belong to an encyclopedia. — Dsimic (talk | contribs) 17:40, 14 February 2016 (UTC)

Well, thanks people. I believe the unceremonious mention of LFS was mainly to blame for the perceived level of intelligibility (or the lack, thereof). I'll dig around for other sources explaining the issue and will try to re-write the contribution. I'd have attempted a repair if I knew how I can do it by editing alone. The whole contribution is Greek to me. Fortunately, the source itself is intelligible.

Now another issue: The source itself is an open Wiki but it is written by a Microsoft employee and has received c.e. from Vadim Sterkin. Should we accept the source as reliable?

Best regards,

Codename Lisa (talk) 18:51, 14 February 2016 (UTC)

You're welcome, we're all here to help each other. I just spent about ten minutes trying to find some official Microsoft documentation about the NTFS changes introduced in Windows 8, and surprisingly found none. All I was able to find is another blog post, which wasn't that great, and some forum posts. With that in mind, I'm not sure whether we should accept the source as reliable, simply because it seems to be the only available description of those NTFS changes. It would be great if we could find other reliable sources. — Dsimic (talk | contribs) 19:24, 14 February 2016 (UTC)

The contribution was made mainly to allow readers to understand that version numbers are not sufficient to describe different architectural implementations of NTFS, particularly for NTFS version v3.1 that used Log File Service version 1.1 before Windows 8 or Windows Server 2012 and then LFS version 2.0 afterwards The hyperlink was provided to show that Microsoft had publicized the interoperability issue before, and the filesystem check observations were made so that someone could immediately verify the interoperability issue, rather than taking the risk of losing files when getting the false warning. Note that as of Windows 10 build 14342, NTFS drivers have not been updated to be backwards-compatible with the LFS 1.1 flavor of NTFS 3.1 showing errors on a volume created under Windows 7 that is totally error-free, and then attempting disruptive repair, and vice-versa. This is important for users having different partitions or drives in a computer with different LFS implementations and simultaneously accessible, as no Windows operating system to date is able to handle both LFS 1.1 and LFS 2.0. Cquarksnow (talk) 16:58, 21 May 2016 (UTC)

I did not revisit this talk as the article did not differentiate NTFS 3.1 versions by LFS, except in the journaling section, yet what I was trying to infer is that if one dual-booted Windows 7 and then Windows 8 or 10 or 11 without disabling chkntfs.exe, there was a potential for a dirty bit on the Windows 7 partition, asking for recovery (that I naïvely opted for), but fortunately I had multiple file backups. As I went directly from Windows 7 to Windows 10, I did not stumble upon the Microsoft Technet article mentioned above yet thought of mentioning it for whoever went directly from Windows 7 to Windows 10 with dual booting so as to have a fallback, if not immediately realizing that the dirty flag arises out of a journaling change and looking for this in Wikipedia. I also found out that Windows 11 uses also NTFS 3.1 LFS 2.0. This article contains several references to artifacts of NTFS LFS version changes, including the effects of chkntfs.exe setting a dirty bit and then running chkdsk.exe from a Windows version prior to Windows 8, notably in multiboot environments. Cquarksnow (talk) 00:03, 9 December 2021 (UTC) — Preceding unsigned comment added by Cquarksnow (talk • contribs) 23:49, 6 December 2021 (UTC)

Directories are B-trees

Hi, I'm new to editing any pages on Wikipedia. I couldn't figure out how to send a private message to EncMstr so I decided instead to try to use the talk page of NTFS.

There are a lot of inaccuracies in this page and I am willing to help out to improve the page. I'm an NTFS developer at Microsoft, and having worked on NTFS for 8 years, I'm an expert. I'm a first hand source of information. However Wikipedia requires tangible references, and I totally acknowledge that, so I may not actually be able to contribute much if I can't find some sort of reference that agrees with me.

Anyway my first attempted correction was that NTFS uses B-trees for its directories, not B+ trees. I removed the references to Russinovich's article because it was unfortunately incorrect. Russinovich knows a lot about NTFS, but he is not an expert, and he can make mistakes. That article was also written a long time ago. To Russinovich's credit, in the latest Windows Internals (Sixth Edition), chapter 12, under the heading "Indexing", the text correctly describes directories as B-trees. I will also point out that Wikipedia's own article on B-trees lists NTFS as an example file system that uses them, while the article on B+ trees lists other file systems (such as ReFS) but not NTFS; hence Wikipedia is internally inconsistent on this detail.

EncMstr mentioned to look in the Linux NTFS source code, where it purportedly describes the structure as a B+ tree. Unfortunately I cannot look at the Linux NTFS source code due to my job. If it describes NTFS directories as a B+ trees then that's incorrect.

Just trying to help out. Appreciate the time you guys put into this. — Preceding unsigned comment added by Craigbarkhouse (talk • contribs) 07:50, 16 August 2016 (UTC)

Update: Decided to take a look at the NTFS page again (May 2018) and noticed somebody did finally correct it to B-tree like I had originally tried to do. I wish you would accept information from first-hand sources, I mean I understand why you are reluctant to, but it just dooms the page to be forever inaccurate and incomplete. For instance that new stuff added about OneDrive and "recursive linking"... that has me puzzled, since there's no recursion anywhere, I just have no idea what you're trying to describe with that. I could tell you the important details, since I worked on it, but it is established you won't accept such information. Yet that paragraph about OneDrive somehow stays on the page when it is all speculation and doesn't link to a single reference. I thought you had a policy of requiring references? — Preceding unsigned comment added by Craigbarkhouse (talk • contribs) 08:49, 15 May 2018 (UTC)

Updated, with sources. Think this version makes a little bit more sense. Fingers crossed. AlistairMcMillan (talk) 22:14, 3 April 2021 (UTC)

NTFS on >2.2 TiB drives

Under Features->Scalability, it says that NTFS requires a GPT partition table to make a single volume greater than 2.2 TiB. Many people on forums also claim this. However, I'd like to point out that there is a workaround involving 4K sectors. The 2.2TiB limit applies only to 512-byte sectors and I actually own an 8 TB hard drive with MBR and 4K sectors that works on Windows XP as one NTFS volume. I propose that we change the statement to reflect that it applies only to the standard 512-byte sector.

As verifiability is important on Wikis, here are 2 screenshots proving my point: 8TB drive on XP, System Information showing sector size. — Preceding unsigned comment added by 2602:306:CE68:8DE0:942C:3044:3EB3:9B7 (talk) 20:02, 14 June 2017 (UTC)

Hi.

Yes, verifiability is very important in Wikipedia, and you do not have a good grasp of what it is. Your screenshots do not construe reliable sources.

Best regards,
Codename Lisa (talk) 10:42, 15 June 2017 (UTC)

Hi Lisa,

Thank you for pointing out my mistake. I suspected something could be wrong with my info so I'm glad I discussed it in Talk first. Very few people know about using MBR with large sectors so it'll be a while before suitable evidence is available. — Preceding unsigned comment added by 2602:306:CE68:8DE0:5C6:41AB:EB14:75E4 (talk) 23:15, 16 June 2017 (UTC)

harmonize disjointed, unsourced final sentences of introduction

The last two sentences of the article introduction look like an editor randomly tagged them on yesterday: They are not logically connected to the previous text and consequently look like prohibited "original research". Please rewrite the introduction to logically include these sentences with citations in a unified logical flow, or else delete them. -- Newagelink (talk) 03:25, 31 July 2017 (UTC)

Hello, Newagelink

If by "introduction" you mean the lead section, it needs not have citations of its own, and MUST NOT have novel contents or novel citations not seen anywhere else in the article.

But of course, to say that the lead is far from adequate, is nothing new. It has been tagged as inadequate since 2014.

Best regards,
Codename Lisa (talk) 08:01, 31 July 2017 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 5 external links on NTFS. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20080723180729/https://www.auscert.org.au/render.html?it=7967 to https://www.auscert.org.au/render.html?it=7967
• Added archive https://web.archive.org/web/20041114032240/http://www.codeproject.com/datetime/dstbugs.asp to http://www.codeproject.com/datetime/dstbugs.asp
• Added archive https://web.archive.org/web/20110210152004/http://www.seagate.com/ww/v/index.jsp?locale=en-US&name=goflex-software&vgnextoid=11c1fab114b48210VgnVCM1000001a48090aRCRD to http://www.seagate.com/ww/v/index.jsp?locale=en-US&name=goflex-software&vgnextoid=11c1fab114b48210VgnVCM1000001a48090aRCRD
• Added archive https://web.archive.org/web/20100810084414/http://smokingapples.com/software/tutorials/snow-leopards-hidden-ntfs-readwrite-support/ to http://smokingapples.com/software/tutorials/snow-leopards-hidden-ntfs-readwrite-support/
• Corrected formatting/usage for http://www.free-av.com/en/tools/11/avira_ntfs4dos_personal.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 19:42, 14 September 2017 (UTC)

Windows 10 v1709 and Windows Server, version 1709 extended the cluster size to 2 MB

Here's why implemented it

External links modified (February 2018)

Hello fellow Wikipedians,

I have just modified one external link on NTFS. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20150123140513/https://technet.microsoft.com/en-us/library/hh847764(v=wps.620).aspx to https://technet.microsoft.com/en-us/library/hh847764(v=wps.620).aspx

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 01:18, 11 February 2018 (UTC)

False statement

> "Windows Vista adds mandatory access control info to DACLs."

False. Mandatory Access Control (now generally called Windows Integrity Control) is implemented as a new Access Control Entry (ACE) type in the System Access Control List (SACL) - not the Discretionary Access Control List (DACL).

> "The ... system access control list (SACL), defines which interactions with the file or folder are to be audited ..."

Incomplete per above.

TC 04:42, 26 July 2018 (UTC) — Preceding unsigned comment added by 203.24.3.112 (talk)

Usage of KB/KiB, MB/MiB, etc.

Shouldn't we use KiB instead of KB (respectively for MB, GB, ...) in many cases regarding sizes? I know that Microsofts NTFS site regarding cluster sizes also uses kilo units (e.g. KB instead of KiB) but I guess that this is inaccurate. For example: The maximum cluster size should be 2 MiB instead of 2 MB, right?

Regards, Hauke-stieler (talk) 07:36, 7 January 2019 (UTC)

Agree – the use of just "KB", "MB", ... for binary kilos, megs, ... is outdated and ambiguous. Where binary prefixes are useful (like here) these should be replaced by KiB, MiB, ... Where binary prefixes are less useful decimal prefixes should be used in general. --Zac67 (talk) 12:03, 7 January 2019 (UTC)

Disagree – binary "KB", "MB", etc., are the only valid forms. The SI's imposition of decimalisation on computing is a corruption of computer science, and just because they're besotted with base-10 doesn't give them a right to redefine the units of binary computing. 209.93.234.169 (talk) 14:05, 21 October 2021 (UTC)

I disagree with your disagreement (read: Agree with OP) – Even if binary "KB", "MB", etc. were used to start, all that we accomplish by continuing to use that is ambiguity with other units of measurement. The SI's redefining "KB" and "MB" to powers of 1000 B is, in my opinion, good for consistency. Also, while I do believe that binary computing is still ideal, I sometimes see decimal computing used, e.g. by storage manufacturers. For disambiguation, we should count powers of 1024 using a modified prefix, and "KiB", "MiB", etc. is a great way to do that. —Rain Shinotsu (talk) 00:48, 24 February 2023 (UTC)

I also disagree with you and therefore Agree with OP. Computer science's imposition of binarisation on SI units is a corruption of the metric system, and just because they're besotted with base-2 doesn't give them a right to redefine the units of decimal SI prefixes. These metric prefixes predate their use in computing by decades to centuries. AwaweWiki (talk) 19:37, 12 February 2024 (UTC)

Agree binary units are the most unambiguous Wqwt (talk) 17:16, 30 July 2023 (UTC)

What are namespaces?

The article mentions namespaces, specifically a "Win32 namespace" and a "POSIX namespace" and a "DOS namespace", but does not explain what they are (as far as I can see). – Tea2min (talk) 10:25, 5 March 2019 (UTC)

UTC vs UT

In a number of places it is said that NTFS keeps timestamps in UTC, or that Windows maintains UTC time (and so allows NTFS timestamps to be UTC.)

Is this correct? Note, UTC involves leap seconds, while UT does not.

Windows does not appear to have any knowledge of leap seconds, so the UTC claim is a bit curious.

NTFS time stamps and/or the Windows FileTimeToSystemTime conversion code (and vice versa: SystemTimeToFileTime) do not appear to provide leap second support in any way.

More likely, it's a misunderstanding, based on default time services providing UTC time, which Windows then maintains as UT and as best it can until the next time synch takes place.Athulin (talk) 10:27, 19 February 2020 (UTC)

implementation: unmovable attributes

I'm using a NAS version of NTFS: it creates lots of unmovable security attributes littered across the volume. Either Windows commonly uses a reserved space for extended attributes, or the non-windows NTFS implementation is only able to use extended attributes, or some other reason. I'm interested in reading about implementation differences. — Preceding unsigned comment added by 121.200.27.15 (talk • contribs) 09:15, July 6, 2021 (UTC)

Total sectors

By observation with how Windows 10 21H1 creates/amends the NTFS boot sector, the "Total Sectors" value at offset 0x28 is actually "The partition size in sectors minus 1". Simon Arlott (talk) 13:40, 4 September 2021 (UTC)

reserved space at start

According to Boot Sector (MSDN, 2008):

0x0E0 x0100
Reserved Sectors . The number of sectors preceding the start of the first FAT, including the boot sector. The value of this field is always 1.

The other relevant cite NTFS Partition Boot Sector (NTFS.com) says only

0x0E 	WORD 	0x0000 	Reserved Sectors

Presumably Microsoft's documentation (which is demonstrably more extensive) is more reliable than a third-party source TEDickey (talk) 09:34, 13 June 2022 (UTC)

Your eyes don't seem to see "Table 1.7 BPB Fields for FAT16 Volumes".116.199.247.46 (talk) 14:15, 13 June 2022 (UTC)

I quoted from that table. Perhaps you can quote the exact text which differs TEDickey (talk) 08:29, 14 June 2022 (UTC)

You quoted from table 1.7 which is about FAT16 volumes. Table 1.13 which is about NTFS volumes seems to say exactly the same as the ntfs.com source. AlistairMcMillan (talk) 17:40, 14 June 2022 (UTC)

Thanks (got lost in the article). I added the table name to the reference to help with this and related issues TEDickey (talk) 19:19, 14 June 2022 (UTC)

It's strange that you weren't interested in the "The value of this field is always 2" in the line just below you quoted.

0x10 BYTE 0x02 Number of FATs . The number of copies of the FAT on the volume. The value of this field is always 2.

60.43.42.116 (talk) 03:49, 17 June 2022 (UTC)

IEC unit shenanigans

WP:COMPUNITS is clear [t]he IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used with only a few narrow exceptions, none of which apply here. The article uses these units in one meaning only, however both kbrose and Zac67 have reverted my improvements back to revisions that mix the units needlessly, often even in the same sentences:

• "256 TiB − 64 KB"
• "16 EiB – 1 KB (format)"
• "8 PB – 2 MiB"

As the reliable sources for this article all use the non-ibi (the traditional kilo/mega/giga/tera/peta) units, it does not make sense to cause confusion for our readers by having these mixed units (which are referring to the same unit of measure; there is no binary/decimal ambiguity here). The only alleged ambiguity that exists now for our readers is why we're using two different unit formats for the same meaning, sometimes within the same sentence/use. In addition to WP:COMPUNITS and the sources in this article, see here for further discussion on why the units generally should not be used on Wikipedia. —Locke Cole • t • c 15:35, 6 October 2022 (UTC)

WP:COMPUNITS does define exceptions to the cited rule that you commonly omit – don't get started, I don't think that any of them apply here. The problem with your edits is that you removed the clearness created by the IEC prefixes and replaced them by ambiguous-to-misleading kilo, mega, giga, ... You cannot expect the casual reader to know that these prefixes carry a non-decimal meaning here. I did try to tell you but apparently you weren't reading. As noted previously, WP:COMPUNITS clearly states (emphasis mine) Do not assume that the binary or decimal meaning of prefixes will be obvious to everyone. Explicitly specify the meaning of k and K as well as the primary meaning of M, G, T, etc. in an article ({{BDprefix}} is a convenient helper). Consistency within each article is desirable, but the need for consistency may be balanced with other considerations. Linking to megabyte isn't sufficient because the linked article only discusses the ambiguity and cannot clear it up. So, please add such a specification for the article in general and make sure you mark any decimal exceptions to that appropriately. --Zac67 (talk) 19:29, 6 October 2022 (UTC)

The problem with your edits is that you removed the clearness created by the IEC prefixes Can you explain how the portions I cited above are less ambiguous? So, please add such a specification for the article in general and make sure you mark any decimal exceptions to that appropriately. I'm not sure if you just don't understand the topic that you're revert warring over, but there are no exceptions within this article. There is only one in use. —Locke Cole • t • c 06:35, 7 October 2022 (UTC)

The mixing is bad and needs fixing, no question (as there's no good reason for mixing). Possibly, the editor had the impression that capital K isn't ambiguous, but that isn't important. But even you might agree that IEC prefixes are not ambiguous. Removing them altogether fixes the mixing problem, but increases ambiguity. All that is required when removing the IEC prefixes is to explicitly specify the meaning of the ambiguous k/K/M/G/T/P prefixes. You state that there are no exceptions in the article, so a single note at the top should suffice. When you are the one making the change it's your task to ensure that. You cannot expect other editors to include the note, or to check the article for any exceptions (which you seem to have done already). And for the record: I wasn't the one edit warring, you were. (In accordance with WP:BRD, you were bold, I reverted, and then you failed to discuss but started reverting yet again.) --Zac67 (talk) 13:10, 7 October 2022 (UTC)

When you are the one making the change it's your task to ensure that. Absolutely not. There is no requirement that all improvements be done at the same time. Otherwise people making minor spelling corrections could be reverted because they left a grammar issue unfixed. Or any other issue, for that matter (see WP:NOTFINISHED). It's patent nonsense, and just you searching for an excuse for your behavior. My edit was an improvement for our reader as it removed any ambiguity over whether there were different meanings for the units expressed, especially for the three examples I gave above. Now our readers will need to dig into the sources to determine if there's actually two units in use, or if people (us) editing this article are just too stupid to use one (the one being used in our sources) and be done with it. And for the record: I wasn't the one edit warring, you were. Typical abusive behavior answer. As you have no valid reason for your reverts, you're just reaching now. Anyone reading this can see this for what it is: it's not that I didn't do something I was supposed to do, it's that you would rather revert war than do the thing you just described. You're not here to create an encyclopedia, you're here to push your POV. —Locke Cole • t • c 16:14, 7 October 2022 (UTC)

Quondum apparently has sources for all those -ibibyte units they just added, I hope? Or is WP:V just a gentle recommendation and if you like something enough that should be all that matters? —Locke Cole • t • c 15:30, 8 October 2022 (UTC)

Minus signs and dashes in the infobox

Looks like we have some typos in the infobox. In the "Max. volume size" and "Max. file size" fields there is a mix of minus signs and dashes, and I'm pretty sure they are all supposed to be one or the other. For example, is "2⁶⁴ clusters − 1 cluster" supposed to be (2⁶⁴ minus 1) (in which case why doesn't it say "2⁶⁴−1 clusters") or is it supposed to be the range of values from 1 to 2⁶⁴ (in which case why isn't it in ascending order)? GA-RT-22 (talk) 02:23, 11 October 2022 (UTC)

As I understand that box, those are all "-" minus signs. Maximum xyz indicates an upper limit, not a range of choices; this is reflected in the source as well. --Zac67 (talk) 08:11, 11 October 2022 (UTC)

Changing references of NTFS to “NT File System” from “New Technology File System”

I made changes to the terminology of NTFS on Wikipedia to align the article with the accurate historical context and to ensure that it adheres to Wikipedia’s policies on verifiability, reliable sourcing, and neutrality. Specifically, I revised references to NTFS as the “New Technology File System” to the more accurate “NT File System,” based on credible accounts from Microsoft software engineers and former employees.

Verifiability and Reliable Sources (WP:V, WP:RS)

Wikipedia’s core content policies, particularly ‘’‘verifiability’’’ (WP:V) and ‘’‘reliable sourcing’’’ (WP:RS), emphasize the need for information to be backed by reliable, third-party sources that are directly relevant to the subject. The term “New Technology File System” has been perpetuated more by marketing narratives than by technical accuracy. According to credible sources, including insights from key Microsoft personnel, “NT” actually originates from the code name “N 10,” which was part of the development process for the operating system, not from “New Technology.” Furthermore, I cannot find one official reference to NTFS as "New Technology File System" on Microsoft's web site.

By reflecting this origin, the Wikipedia article will be more aligned with the truth, supported by firsthand accounts from those directly involved in the development of NTFS. This change ensures that the article meets Wikipedia’s standard of being well-sourced and factual, rather than relying on outdated or oversimplified marketing terminology.

Neutral Point of View (WP:NPOV)

Wikipedia’s ‘’‘Neutral Point of View’’’ (WP:NPOV) policy requires articles to represent information fairly, proportionately, and without bias. The continued reference to NTFS as the “New Technology File System” skews the article towards a narrative that was primarily a marketing tool rather than a technical fact. This creates a bias that favors a simplified and inaccurate history of NTFS.

By correcting the terminology to “NT File System,” the article remains neutral, presenting the information as it is, without the influence of promotional language. This change ensures that readers receive an unbiased account of NTFS’s history, rooted in the factual origin of the term.

Aligning with Wikipedia’s Mission (WP:MISINFO)

Wikipedia’s mission, outlined in policies like WP:MISINFO, is to provide accurate and reliable information to its users. The change from “New Technology File System” to “NT File System” supports this mission by ensuring that the article reflects the most accurate and current understanding of the technology’s history. It prevents the perpetuation of myths or misunderstandings and instead offers a clearer picture of how NTFS, and the NT architecture as a whole, developed.

This change is not just about correcting a name; it’s about providing readers with the most truthful account, based on verifiable information. It enhances the article’s credibility and helps fulfill Wikipedia’s goal of being a reliable and trustworthy source of information.

TLDR

The revision of NTFS terminology in the Wikipedia article is a necessary update to align with the platform’s policies on verifiability (WP:V), reliable sourcing (WP:RS), and neutrality (WP:NPOV). By referring to NTFS as the “NT File System,” the article becomes more accurate and reflective of the technology’s true origins. This change upholds Wikipedia’s standards and ensures that readers are provided with information that is both factual and free from outdated marketing narratives. — HiB2Bornot2B ^talk Go Big Blue! 20:57, 8 August 2024 (UTC)

References seem to be somewhat thin on the ground for either name. The Microsoft glossary entry, which uses "NT File System", is probably the best reference for the current meaning of "NT" in "NTFS".

A pretty good citation from the Intel i860 page indicates that "N10", Intel's code name for the first-generation i860 XR, was the original source of "NT", as it was the instruction set on which NT development began. That reference says that x86 was not the first target; that port was done later - "We stayed away from the 386 for a while to avoid getting sucked into the architecture ... We didn't want to use non-portability assumptions."

That reference also says that, according to one of the Microsoft developers, "the "new technology" moniker was added after the fact in a rare spurt of product marketing by the original NT team members", suggesting that, for at least a period of time, NT did stand for "new technology", but that wasn't it's original meaning. That doesn't mean that the "NT" in the file system name stood for that; it might just have stood for "NT", as in "a file system for Windows NT". Guy Harris (talk) 22:33, 3 September 2024 (UTC)

References