Talk:NTFS/Archive 1

Archive 1

Archive 2

B-Trees

Does NTFS use binary trees or B-trees? My understanding is that they're not the same. Or maybe it's HPFS that supposedly uses B-trees. Scott McNay 23:09, 2004 Feb 13 (UTC)

NTFS uses B-trees (see: [url=https://www.i.u-tokyo.ac.jp/ss/lecture/new-documents/Lectures/08-NTFS/NTFS.pdf]). B-trees are easier to maintain and faster (in overall performance) than binary trees. michalj 23:09, 25 Jun 2004 (UTC)

B-trees may have some performance benefits over binary trees (which are a family of structures rather than a specific structure) but they're absolutely not easier to maintain; the coding of a B-tree (or B-tree variant, such as B*tree, B+tree) is rather more complex than that of e.g. a Red/Black tree, AVL tree, splay tree, a heap. It is the way that a B+tree keeps its data all in the leaves and links the leaves themselves (so one can iterate through the leaves without having to iterate through the tree's internal nodes) that makes it useful for filesystem usage, not any ease of implementation. DrPizza 12:49, 30 September 2005 (UTC)

Officially from Microsoft documentation, NTFS and HPFS uses B+Trees, they are not the same as B-Tree. --Claunia 22:27, 12 Aug 2005 (GMT)

Fragmentation

Can we have some more discussion about fragmentation? How come Microsoft Windows NT 4 didn't include a defreg tool, but Microsoft Windows 2000 did? Edward 12:35, 12 May 2004 (UTC)

Marketing. Easier to include a basic defrag tool than put up with FUD from the likes of Executive Software about the evils of fragmentation. In reality, fragmentation-induced split I/Os are really rather unusual. DrPizza 12:49, 30 September 2005 (UTC)

Not quite: Lance Jensen & his crew at Executive had a license to the NTFS version in NT 3.51, which led to the original MoveFile() API. In NT4, the MoveFile() API was embedded in the operating system; but it was left up to Executive and Raxco to use it. Symantec's Speed Disk did not use this API, and it led to a LOT of grief. Dan Schwartz, Mac-NT Mailing List Moderator Discpad 21:44, 13 March 2007 (UTC)

ADS

Someone created a stub for the Alternate Data Streams (needs a lot of clean up) that exists in NTFS. The NTFS article doesn't link to it (the only thing that does is the disambiguation page for ADS). I marked the name here as bold rather than link in case we want to to just be orphaned off. Does anyone here know enough about ADS to make the ADS article meaningful? Should this article link to it? RJFJR 19:54, 19 Dec 2004 (UTC)

I work for Microsoft on NTFS, and I'd be happy to help document the behavior of this topic; what is it specifically that you'd like cleaned up or added to it? --Malx 01:15, 28 May 2005 (UTC)

Surely the ADS "limitation" listed (that streams don't copy to non-stream-capable filesystems) is by definition a limitation of those other filesystems and not of NTFS? It seems rather out of place. I mean, it's like saying that my hard disk has a "limitation" because I can't back it up to a single floppy disk. DrPizza 14:37, 27 September 2005 (UTC)

• Something definately needs to be mentioned about the HUGE security risk that ADS poses. I only found out about this from a PC mag the other day and I'm amazed that anyone would use NTFS after this! Do you realize that a virus EXE can be stored in the ADS of a text file. It's impossible to find the exe in windows unless you already know it's there, it won't change the reported size of the text file in Explorer, and the exe can be run from the registry or whereever simply by the string:

  c:\path\to\textfile.txt:nameofvirus.exe

  There is also no limit to the file size of the ADS. A 10 byte text file can have an ADS of 2 Gig! A nice way for a trojan to fill up the hard drive, and you'd never be able to find it! Oh and by the way out of all the main virus scanners McAfee seems to be the only one that will scan inside ADS streams.

--gorgan_almighty 10:56, 28 November 2005 (UTC)

• I've added a few relavent links to the ADS page. I've also added the security information there.

--gorgan_almighty 12:53, 28 November 2005 (UTC)

Just, that security problems, are of Explorer and related Windows programs, not of NTFS itself.

HPFS, MFS, HFS, HFS+, ext2, ext3, JFS, XFS, ReiserFS, all support ADS, and none have that security issues, why?

Because their OSes utilites are aware of ADS, but Microsoft's ones treat them almost as inexistents.

I think, this has NOTHING to do with NTFS, and should be just commented in ADS page as an issue in Microsoft's disk utilities and Windows maintenance (antivirus, etc) applications, but not as a NTFS problem by itself (the problems also happens on CIFS shares, no matter if the host is NTFS or another ADS-aware filesystem, for example, HFS exported via DAVE)

—Claunia 14:53, 28 November 2005 (UTC)

Uhh, guys: Extra streams were always included in NTFS: It is how dual fork Mac files were able to be stored in Services For Macintosh (SFM) in the server versions all the way back to NT 3.11. And No, they are not stored in a single MacBinary-style file, nor are they stored in two separate files like Apple's DOS disk (FAT disk) stores them. Dan Schwartz, Mac-NT Mailing List Moderator, Expresso@Snip.Net Discpad 21:50, 13 March 2007 (UTC)

Compression

Compression is barely mentioned.

"New Technology File System"

I've just changed the expansion of the name in the article from "New Technology File System" to "NT File System", because according to Windows NT the origin of the "NT" designation is obscure, and "the letters were expanded to "New Technology" for marketing purposes but no longer carry any specific meaning". The "NT" in "NTFS" is presumably just a reference to the "NT" in "Windows NT", and therefore equally unexpandable. If anyone thinks I'm wrong, and that MS does in fact treat "New Technology File System" as the correct expansion, feel free to say so and revert my change. - IMSoP 17:57, 21 August 2005 (UTC)

That Microsoft changed opinion about their own "NT" meaning was just for marketing purposes, as just the same pain with HFS (changed from Hierarchical to Mac OS to Mac OS Standard, huh :S), but as when in development it meant "New Technology" it should remain as that. - Claunia 05:54, 22 August 2005 (UTC)

No, I think you've got it the wrong way round - according to our Windows NT article, it probably stood for something else during development, and became "New Technology" later, purely for marketting purposes. But it may be that, specifically, "New Technology File System" is accepted as the canonical expansion of the term "NTFS" - even though "Windows NT" can't really be expanded (and "NT Technology" is probably not an example of RAS syndrome). If (and probably only if) that's the case, then we should put the expansion back. - IMSoP 19:07, 22 August 2005 (UTC)

Regardless, Microsoft still refers to it as New Technology File System on their own website. Example: https://support.microsoft.com/default.aspx?scid=kb;en-us;320866. I'd appreciate people actually pointing out why Microsoft still refers to it long-form and not just third-party websites before they conclude that it is simply just NTFS. In fact, according to Google there are over 80 direct mentions on the microsoft.com domain and subdomains referring to NTFS as New Technology File System ( Google Results on Microsoft.com for New Technology File System).Quadra23 03:25, 31 October 2005 (UTC)

Microsoft Manual of Style for Technical Publications (they had it on their download page, but removed since then) says this explicitly in Appendix A, List of Acronyms and Abbreviations:

Acronym	Meaning	Comments
NTFS	NTFS file system	The redundant phrase is correct. Do not use NT file system or New Technology file system.

FYR, a version of this appendix seems to have persisted in Google cache --tyomitch 13:51, 4 September 2005 (UTC)

Well I have nothing against that but, every filesystem designer give it a name, then abbreviates it, then says only the abbreviation should be used. I think that the expanded name should remain, here, and everywhere. —Claunia 00:29, 5 September 2005 (UTC)

This article has external link to Microsoft NTFS Technical Reference which a) never spells out NTFS; b) uses the phrase NTFS file system occasionally. Perharps they know better how their product is called? For the sake of comparison, FAT is spelled out in the What Is NTFS? section, so that's not just avoidance of spelling out acronyms. --tyomitch 07:46, 5 September 2005 (UTC)

Funny, I was always told it stood for Native Transactional File System. Dan Schwartz, Expresso@Snip.Net Discpad 21:46, 13 March 2007 (UTC)

Source? Searching microsoft.com for "Native Transactional File System" results in zero hits.[1] AlistairMcMillan 22:28, 13 March 2007 (UTC)

Same with Microsoft's own search engine: [2] AlistairMcMillan 23:08, 13 March 2007 (UTC)

Reserved File Names

It is also not possible to create a file named "aux" in NTFS.

Yes it is. The entire list of reserved filenames is incorrect, as not one of them are reserved. I put in a correct list of reserved filenames, but some idiot removed it and reinstated the current incorrect list. Every single one of the names listed presently can be created on NTFS volumes. If there is any doubt, disk images and/or screenshots can be provided to demonstrate this point beyond any doubt. The current information is simply flat out wrong.

Hello, DrPizza, and for the record, the name you have called me applies to yourself first and foremost since you made no discussion prior to making your radical "across the board changes" as is standard procedure across Wikipedia, for again, such large changes. You could have at least documented it here before posting -- which you obviously neglected to do. I was polite to you in the entire process, if you want to work against the grain, just as your comment language now proves and in the discussion, that is your choice and shows your inability to work as a member of a team of editors. This was clearly shown in your own words in your own Talk page. I'm saddened by how your immature behaviour in this matter reflects on Wikipedia when it shouldn't. Quadra23 Sept. 29, 2005.

Replacing one small list with a correct list hardly constitutes a radical change. Why document it here (where essentially no-one will read it) when I can simply fix the article (and so stop misleading people)?

NTFS for other systems?

How about listing the various implementations of accessing NTFS from other operating systems?

Winternals used to sell "NTFS For Win98" but no longer does. It's final version was 2.0, which supported all versions through XP. They still sell their NTFSDOS product. These require some files from Windows NT, 2000 or XP. Using the files from newer versions works for mounting NTFS volumes from older versions.

Paragon currently markets an NTFS product for Win98 and WinMe here. https://www.mount-everything.com/home/ntfsw/index.htm They also have a Linux version. Free "demo" versions for both that only allow read access are downloadable. The Windows version claims compatability with USB attached drives.

Sysinternals has a free, read only NTFS driver for Windows 98. It uses the same extra files as Winternals' did. It doesn't appear that they have a read/write version available.

Isn't anyone doing an open source NTFS driver for Win9x and Win Me with read/write capability? —Preceding unsigned comment added by 67.136.145.213 (talk • contribs) 09:16, 6 September 2005

Put that in external links

—Claunia 10:13, 6 September 2005 (UTC)

The Linux NTFS driver, available here https://www.linux-ntfs.org/ has full read support for NTFS and limited write support (it can only overwrite existing files, but cannot create new files or delete existing files). I think native write support is very much alpha. —The preceding unsigned comment was added by 131.170.90.2 (talk • contribs) 05:13, September 18, 2006 (UTC)

NTFS compatibility between 64/32 bit systems?

I've heard reports that 64-bit versions of Windows 2003 won't recognize NTFS filesystems created on 32-bit versions; anyone able to experiment and confirm/disprove? —Preceding unsigned comment added by Fencepost (talk • contribs) 22:19, 12 January 2006

I would really doubt this. Microsoft put a lot of effort into backward compatibility. Do you have any sources to back this up? AlistairMcMillan 23:49, 12 January 2006 (UTC)

Disk 0 Partition 1: NTFS from Windows XP IA-32

Disk 1 Partition 1: NTFS from Windows XP x64

Disk 2 Partition 1: NTFS from Windows XP IA-32

All are perfectly accesible from each operating system.

Is to suppose that Windows 2003, and IA-64 versions, work equal.

Windows Vista drives are also accesible under previous Windows just if you do not create any symbolic link.

—Claunia 13:52, 13 January 2006 (UTC)

With Vista, drives with symbolic links, transactions, or any other Vista feature will mount backlevel, but those particular files may not be accessible.

—Malx 10:00, 14 April 2006 (UTC)

I suspect the user is getting confused between GUID disks and MBR disks. GUID was introduced with Windows XP IA-64 but also included in Windows 2003 and now Windows XP x64 and I guess all versions of Vista. Of course, only Windows IA-64 versions can boot with GUID disks... Nil Einne 23:23, 29 March 2006 (UTC)

Unlimited files

The article claims that there is no limit on the number of files NTFS can store, but surely there must be... becuase each file must at least consume some space for its name, and there is a maximum volume size. --24.165.233.150 21:31, 6 September 2005 (UTC)

There is a first limit when you format a drive with NTFS, as the $MFT is created with a limited number of records.

When you need to create more files, the $MFT is expanded.

And so until you get out of space.

So, it is unlimited, because you can have a 3Gb drive with an $MFT sized on 2Gb and 1Gb on files, or a 3000Tb drive with an $MFT sized ni 2999Tb and 1Tb on files.

Just, of course, everything has a limit, that is mathematical, but the limit is so huge that is inhuman. You want us to write in "number of files" more numbers that we known for the Pi number? We can of course, but, that is "unlimited".

The limit has only sense on filesystems that uses a number to locate files (like HFS) or a fixed size allocation scheme (like the FAT).

So taking acount the NTFS supports 64Eb drives and that each $MFT record is 4Kb in size (I don't remember exactly, but I think it is around that), you can have 2305843009213693952 files (if my calculator isn't non-working today). Happy?

Unlimited means you have no limit on expanding the number of files but the disc size limit itself.

I think, it is explained

— Claunia 02:57, 7 September 2005 (UTC)

Doesn't NTFS offer only a 64 bit address space (with implementations limited to 48 bits)? That makes a total size of 2^64*65536 bytes (if 64kb clusters are used), i.e, 1208925819614629174706176 bytes. —Soumyasch 12:20, 24 February 2006 (UTC)

Well yes but using cluster bigger than 4Kb makes some NTFS characteristics stop working, like EFS and compression.

—Claunia 13:56, 24 February 2006 (UTC)

Reserved Characters

I fail to see how \ and : can possibly be permitted in filenames. \ and : are used for directory and attribute/stream separators. If the filesystem allows them to be used in filenames then it no longer has any way of disambiguating between certain names, for example, it cannot tell the difference between a reference to "foo\bar:baz" (stream 'baz' of file 'bar' in directory 'foo') and a reference to "foo\bar:baz" (file whose name is 'foo\bar:baz') or "foo\bar:baz" (stream 'baz' of file 'foo\bar' or "foo\bar:baz" (file 'bar:baz' in directory 'foo'). And that's just with two dimensions (path and stream)--there's also a third dimension (attribute type), which again is delimited with colons. If colons were permitted how could you tell the difference between "foo::$DATA" (default data attribute of file 'foo') and "foo::$DATA" (a file whose name is 'foo::$DATA'), and so on and so forth.

How do you create files with backslashes and colons in their names, and how does the filesystem deal with ambiguous names? My contention is that you can't (and so it doesn't have to), and all evidence I've seen supports this assertion. Attempting to create files with colons in their names consistently creates files with streams (or files with non-colon characters in their names, as SFU does--try touch "foo:bar"; it creates a file with no named streams, but equally, no colon in its name).

Initial experimentation does sugges that / is also forbidden, though the reason for that is unclear, as I believe only Win32 with unescaped paths treats / as a directory delimeter (or rather, it convers forward slash to backslash behind the scenes); raw (unescaped) paths can't use slashes, which strongly implies that the FS driver won't regard them as directory separators. But then, it doesn't use them for anything else either. DrPizza 23:23, 3 October 2005 (UTC)

Just, read the Inside NTFS Filesystem by Helen Custer, or do as I did, take another implementation, maybe using the POSIX subsystem in Windows NT/2000 or outside it.

As part of the POSIX compatibility, NTFS must support ":" and "\" as characters, as in POSIX the only forbidden character is "/".

Nope, the POSIX subsystem can't do it. It can create files with :, *, and ? in their names but they're not stored as :, ? , or *. This is not surprising when one considers the requirements of the FS (in Windows, filesystems themselves perform wildcard handling, so can't easily treat ? and * as regular characters, and NTFS uses \ as the directory delimiter, : as the stream/attribute delimiter).

Are you sure it cannot? I did not tested, but, however, NTFS is POSIX certified and a requirement for that is supporting any character in the filename but "/".

Yes, I'm sure. Try it for yourself. Some characters it simply refuses to create (e.g. forward and backward slash, angle brackets), others it pretends to create (colon, star, question mark) but doesn't (the POSIX subsystem shows the characters in the filename, but Win32 and the kernel API show that a different character is being used--I'm presuming that some kind of translation is performed by the POSIX subsystem). I believe it maps them to characters in the unicode range above 0xf000. Samba uses the same technique to store such filenames on SMB/CIFS fileshares (i.e. it's compatible with the naming mechanism SFU uses).

Long time ago with the Linux 2.2 NTFS driver in read-write I created the directory "C:" inside the root of my Windows' C: drive, and rebooted into Windows, did chkdsk and everything fine, just the Win32 subsystem is unable to access that directory (but the POSIX one can). The "\" for directory paths and the ":" for streams are just part of the Win32/Win64 abstraction to the NTFS capabilities.

No, they're not; they're what you must use even outside of Win32. Kernel-mode, for example, you still use \ and :, and that's *not* Win32. The colons and backslashes are passed verbatim to the filesystem driver.

Well I don't have the Windows source code, but I can assure you that these characters are fully valid.

Even though the filesystem driver itself won't let you use them?

Implementation != specification, or you think that XFS is how Linux show it and FAT limits are the ones Windows says us?

In the case of something such as NTFS, the implementation rather is the specification. Sure, for things like the maximum size of a file where a 64-bit field is used you can reasonably extrapolate that the filesystem could be extended to support 64-bit file lengths, but in general, the implementation defines the features of the filesystem. There's simply no other source of information on "how things are meant to work". Even if you ignore the particulars of the implementation there is STILL need for AT LEAST two distinct separators. One for path elements, one for streams/attributes. The filesystem simply can't work with only a single separator--it can no longer unambigiously refer to elements on-disk.

In the POSIX subsystem "/" is used for directory paths, and there is no access at all to any stream different than $DATA, so the abstractions changes. Also in Win32/Win64 you cannot use '"' "'" and many other characters, but that is not a limitation of NTFS, nor of the Windows' implementation, just of the Win32/Win64 subsystems.

But that's different; those characters aren't needed by the filesystem itself for paths to be unambiguous. Colon and backslash are. Without reserving colon and backslash it has no way of resolving the questions I posed before.

As I said I don't know how they did, but, they do.

Evidence? If Custer's book really says what you claim it says, it very much appears to be wrong.

If you feel happy making me show you screenshots, I'll do

Screenshots of what? Something like this? https://quiscalusmexicanus.org/downloads/filenameEncoding.png ? Notice how the colon in the filename is--like I said--encoded as 0xf0 0x3a (on-screen it's 0x3a 0xf0 because the 16-bit characters are stored little-endian). It's not a bare colon (0x00 0x3a). It has to be specially encoded. Like I said. NTFS can't store colons in filenames. The POSIX subsystem translates to and from the encoded form, so it looks like it's storing such filenames. But if you look in e.g. Win32 (which doesn't know about the encoding) you get something different. *s and ?s get similarly encoded.

It is just like the space " " in FAT (without LFN), it is not illegal, but as there were no form of using it in filenames, DOS/Windows are unable to use it, but OS/2 for example uses it (just in one file, but uses it), and the filesystem specification and checkers know that it is a legal character filename.

It is for example just like the HFS and HFS+ implementations of MacOS X. MacOS X being a UNIX/POSIX supports any character but "/" and HFS+ supports any character but ":", so when you put in a command line app a ":" in a filename it appears as a (and is stored in the filesystem as a) "/" for Classic/Carbon/Cocoa applications, and viceversa.

But this ISN'T the case for NTFS.

Just abstractions, don't let them to confuse you. —Claunia 00:13, 4 October 2005 (UTC)

Please answer the questions I posed above! DrPizza 08:41, 4 October 2005 (UTC)

I can't answer you better but indicating you to read the Inside NT File System by Helen Custer and taking specially care with the POSIX requirements for a file system reserved characters, as NT and NTFS are POSIX certified. — Claunia 23:23, 4 October 2005 (UTC)

I don't believe this to be accurate, based on simple experimentation with the POSIX subsystem. I don't believe that the filesystem itself actually stores those characters; it very much appears that the POSIX subsystem encodes them in such a way that it can give the *appearance* of containing those characters, without having to actually store them in the filesystem. This would fulfil any POSIX demands but wouldn't require the FS to actually store these characters. DrPizza 08:27, 5 October 2005 (UTC)

Checked hexadecimally the contents of the NTFS metadata to see that?

Ok, so, I will take screenshots for you. — Claunia 10:24, 5 October 2005 (UTC)

I doubt they'll refute my screenshot. DrPizza 22:35, 5 October 2005 (UTC)

First of all, SFU doesn't use POSIX subsystem.

No, it doesn't "use" it. It IS it. SFU installs a distinct NT subsystem that offers a POSIX API. It replaces (in Windows 2000) the OS's POSIX libraries with its own. It's used to run binaries whose subsystem flag is "POSIX" (not Windows GUI nor Windows CUI). Check out their executable headers.

Second of all, POSIX subsystem was removed, along with OS/2 subsystem, in Windows XP onward.

Doesn't matter; SFU reinstates it.

Third of all, there were never available POSIX subsystem binaries from Microsoft, if you want a shell and a ls you must compile it yourself using VC++ and POSIX subsystem (and of course, they will not work in Windows XP).

My Interix 2.2 and SFU 3 and 3.5 binaries say otherwise.

Fourth of all, an image is more than 2^10 words, so these are more than 7*(2^10) words:

https://img283.imageshack.us/img283/6272/fromlinux4hy.png

https://img283.imageshack.us/img283/5689/fromexplorer5kb.png

https://img110.imageshack.us/img110/831/fromcmd5sc.png

https://img110.imageshack.us/img110/7375/chkdsk4kk.png

https://img110.imageshack.us/img110/5994/hexeditor3vf.png

https://img110.imageshack.us/img110/8310/hexeditorcleaned9dp.png

https://img110.imageshack.us/img110/513/hextochar0wo.png

I think, these refute yours, and, discussion is over.

Regards, — Claunia 09:17, 6 October 2005 (UTC)

I don't think they refute anything. You could--with a suitable piece of code--store ANY character in a filename (anything at all, slashes, nulls, etc., regardless of what that filesystems's specification says is allowed or not allowed). What does it prove? DrPizza 09:46, 6 October 2005 (UTC)

If the specification does not support it, why CHKDSK doesn't complain?

What filename checks does it perform at all?

Presence of invalid characters ;)

In which case forward slash isn't reserved either. https://quiscalusmexicanus.org/downloads/slashInFileName.png . Are you now going to say that even slash is allowed? No reserved characters (and hence no way of passing in pathnames!) at all?

NTFS IS POSIX certified, so it MUST store ":" '"' "'" "?" "*" so on, AS THEY ARE, not as abstractions.

Er, which bit of POSIX demands that? Where does it specify the on-disk encoding that must be used? Where does it say not only that an implementation must support such names (which SFU does) but must also *store them verbatim*? Why doesn't the Windows POSIX Subsystem store filenames in the way you describe--why does it encode them specially? And by what process do you get a filesystem "POSIX certified"?

So why when they designed NTFS make support in the metadata for a timestamp, saying "as POSIX required"?

Because there's no way to frig that in the APIs. There is a way (which SFU uses!) to frig the filenames.

And, for second time, SFU doesn't use the POSIX subsystem. And having a subsystem support for it only certifies the subsystem to be POSIX compliant not the filesystem itself.

SFU is the POSIX subsystem. It doesn't "use" it. It is it. And the only thing that MS have ever had POSIX certified is the subsystem + compiler. https://standards.ieee.org/regauth/posix/finalregieee.html Not the filesystem on its own, and, indeed, NIST and IEEE don't appear to have any filesystem certification process, which makes sense, because there's no POSIX filesystem specification (only a POSIX API specification, from which certain filesystem requirements can be inferred; files must have three timestamps, the filesystem must be hierarchical, etc.).

Finally, you get a "POSIX certified" asking the IEEE for it. Then they do an exhaustive check, after what you get the POSIX certification if you comply with all the mandatory specifications.

Links please, as well as some evidence that they require the on-disk format to act as you claim, and not simply the API. In fact, any evidence of certification of "filesystems" (and not C APIs, utilities, compilers, thread libraries, realtime extensions) would be a start.

Read the specification, call Microsoft, do what you want, but I've just demonstrated you that NTFS supports any character but "/", as its specification says.

— Claunia 10:15, 6 October 2005 (UTC)

There is no specification for NTFS. DrPizza 10:23, 6 October 2005 (UTC)

There is one public and somewhat not fully complete (covers the design, implementation and specification of NTFS as Windows NT 3.51 but does not cover the metadata structures), Helen Custer's Inside the NT File System, and one private fully complete that the Microsoft NTFS developers use. Developers doesn't work with air ;)

— Claunia 10:45, 6 October 2005 (UTC)

What is the reason for this discussion now? You saw it, NTFS can have that filesystems and don't complain about them. If you want you can say that Win32 doesn't support them at all and that SFU abstracts them, but, NTFS supports it. P.S.: SIGN your comments. — Claunia 12:01, 6 October 2005 (UTC)

NTFS doesn't support it, which is precisely why SFU abstracts it. NTFS also doesn't perform checking of filenames which is why your test appeared to show the characters were allowed; the on-disk representation itself doesn't need to reserve characters (because it uses counted strings--even embedded nulls are not a problem), but any API must do so (in order to permit the parsing of paths and a distinction to be drawn between names and attributes). The problem that arises as a consequence of your test is that the files are unaddressable, because there's no resolution to the dilemma I posed originally. It doesn't complain about slashes yet you claim that they're resered--you can't have it both ways.

Further facts are NTFS isn't "POSIX certified". There's no such thing for filesystems, only for C APIs (and compilers, utilities, and the things specified in various other POSIX documents, filesystems themselves not being one of them). To conform to the POSIX.1 semantics NTFS need not store verbatim colons and other such characters; the API only need provide the illusion of doing so. This is what SFU does (encoding the names as unicode characters), and similar in spirit to the approach OS X uses on HFS volumes. This is not true for all design features--for example, to conform to POSIX file time/date requirements does require the FS to behave in a certain way--but for naming an abstraction is possible and, indeed, used.

I don't see any real need to sign each and every part of a comment, because the page's history is sufficient to fill in any gaps in the signing. DrPizza 18:48, 6 October 2005 (UTC)

"NTFS also doesn't perform checking of filenames", sure?

Absolutely. Did you look at the picture? Here it is again: https://quiscalusmexicanus.org/downloads/slashInFileName.png

https://img270.imageshack.us/img270/949/illegalfilename2ab.png

Seems that you and NTFS disconform in that opinion.

What more do you need?

That just indicates that you created the filename incorrectly.

It complained about the illegal "/" but not about ":" nor "?" nor "\" nor quotes.

It doesn't complain about / if the filename is properly formed.

If you want to continue discussing the evidence, do that, but I've demonstrated that the only character illegal in NTFS is "/", no matter what you say, what Win32 subsystem say, what SFU say (that you said, it is ANOTHER POSIX subsystem, not the original NT's one), what SFM says (Macs supports "/" but not ":"), or what you think about if a filesystem can be POSIX certified or not (asked IEEE?).

I've demonstrated that NTFS does NOT complain about / because it doesn't check filenames for illegal characters AT ALL.

— Claunia 03:22, 7 October 2005 (UTC)

P.S.: Remember that in Windows you have more than one API: Win32, Win64, WoW, WoW64, POSIX, SFU (different but compatible with POSIX), NTVDM, and the native one.

All access filesystems in a different way, and a thing essential to filesystem implementation is that you do not pass "C:\directory\file" to the filesystem driver because it doesnt know about paths (read NT's IFSKit, IBM's IFS, UNIX's VFS), but the Filesystem API says the filesystem driver to access to file "file" in directory "directory" that is in the root of drive "C:" that is in the VFS API for low level access to sectors (NTFS asks the VFS to sector x of "C:" to read the root, then to sector y to read the "directory" and then to sector z to read the "file"), and how the paths are parsed is a thing of the high level APIs not of the NTFS driver itself.

— Claunia 03:27, 7 October 2005 (UTC)

VFS? Are you thinking of Linux? In Windows, FS drivers receive IRP_MJ_CREATE to open a file, and that IRP contains a full pathname. It's up to the FSD to then interpret that filename, which is why it needs to be able to distinguish between filenames and streams and so on. Specifically, the IRP contains in its stack a FILE_OBJECT, which in turn contains a UNICODE_STRING containing the filename. The path parsing is up to the filesystem driver (which is what allows the filesystem driver to support things like streams relatively seamlessly). This information is all readily available in the IFS Kit. Look it up if you don't believe me. Though Win32 does perform some manipulation of filenames (like conversion of / to \ and some processing of ".." in paths) the escaped form of paths (\\?\C:\...) bypasses that processing. Each driver in turn has a go at handling the filename itself; the first part (\\?\C:\) is handled by the internal Object Manager, the next part (foo\bar:baz) is then passed to NTFS to deal with. DrPizza 08:21, 7 October 2005 (UTC)

You've just demonstrated that currently "/" is an allowed character in NTFS, while wasn't in NTFS as of NT 4.0.

Oh really? https://quiscalusmexicanus.org/downloads/slashNameNT4.png

I've just created the filename exactly as you did, wanna screenshot of hexdump?

Of your corrupt FS? No thanks.

If CHKDSK doesn't check for filenames why complained mine? ;)

Because you corrupted some other aspect of the file's metadata.

Is stupid to say that CHKDSK doesn't check for correct filenames for two things:

First: You SAW it (an old version, but CHKDSK) complaining about a illegal filename

I saw no such thing. I saw a complaint of a corrupted piece of metadata. But I don't see any complaint about filenames.

Second: What kind of developers you think Microsoft have that make a filesystem metadada consistency check skipping checking for illegal filenames?

Because the metadata's consistency is independent of the filenames. The filenames all use counted strings, so it doesn't much matter what the filename is, at least when one is only concerned with structural integrity.

They just started allowing "/" in filenames with your version so there is currently no reserved characters

Or, alternatively, there are reserved characters (there must be, because the FS's API needs them to be reserved) the presence of which in filenames doesn't represent a structural issue with the disk itself.

And remember, the implementation, doesn't make the filesystem.

Due to the absence of any other kind of specification, the implementation absolutely defines the behaviour of the filesystem. DrPizza 17:56, 9 October 2005 (UTC)

— Claunia 08:30, 7 October 2005 (UTC)

Cluster Tip Areas

Can anybody explain what that is? Eraser, a program for secure deletion of files can overwrite this areas. What are they for?

The unused area at the end of the last cluster allocated by a file is called the cluster tip (or the slack space). This unused area is present in most files because space can be allocated only as cluster sized blocks and the contents of the file rarely completely fill all allocated clusters.

Forbidden characters?

Aside from control characters, what characters aren't allowed in an NTFS file name? Dread Lord CyberSkull ✎☠ 12:06, 12 March 2006 (UTC)

Aside from Unicode NULL (0x0000), you can use the caracther you like, at least anything from 0x0020 to 0xFFFF inclusive (I think no one tested with anything from 0x0001 to 0x001F). —Claunia 14:55, 12 March 2006 (UTC)

Well certainly any redirector (< and >) won't work, since these are used for redirection of I/O; also, colons, backslash (\) and forward slash (/) won't work for the same reason. Of course, this is an implementation issue, not a design issue. But I had no problem making this file name:

sdkjgsdk,ask;jfask;sfas.,f.,zxx.z,xv,zvxcqwrqwrqwr][p14-2=014=-2041=-014!#_)!$@_!+)#%+@%)@#$^$#+_)%$&%^+)()&&^(&}I{}{FGf.,gh,.d,ga.fsdk;ajslkjsdgjkldjlsdjgsjggjjhdfjgfgdjfghsldgsjldlhsgkshsd

--SolarisBigot 14:09, 24 July 2006 (UTC)

Versions

I know this is a pet peeve of mine, and I've made these changes before. Can this page please refer to NTFS versions that are technically correct? NTFS 5.0 is two major versions into the future - it will be really confusing if NTFS "5" is still being used to refer to 3.0. (Just the other day I had somebody think "NTFS 4" refered to "NTFS in NT 4".) Malx 10:00, 14 Apr 2006 (UTC)

Hard Links and Symbolic Links

You've still got problems in your discussion of Hard Links and Symbolic Links.

For a start, you've got Hard Links 'similar' to Directory Junctions, which are 'equivalent of a Unix symbolic link'.

But then you've got "The new NTFS symbolic links work in a similar way to the symbolic links that have existed in Linux"

So NTFS Hard Links are equivilant/similar to NTFS symbolic links.

You need to explain that Hard Links share a MFT record, Symbolic Links (apparently) don't. To make that meaningful, you should mention that Hard Links share one set of security settings. Since this whole article is full of references to Unix, you should cross reference to an explanation of how security settings apply to Unix symbolic links.

Also, I'm not happy about the reference to 8.3 filenames in the Hard Link paragraph. The relationship to Hard Links should be clarified. How does a Hard Link differ from other 'file name records'? (david) 218.214.18.240 05:01, 6 May 2006 (UTC)

Oh, and Reparse Points (NTFS 5.0) are used to implement NSS (discontinued after NTFS 4.0)? 218.214.18.240 05:10, 6 May 2006 (UTC)

Please, by all means, help us out and edit the article to fix up inaccuracies! Warrens 05:15, 6 May 2006 (UTC)

Sorry, but the thing is, I came here to see if I could find the difference between NTFS hard links and NTFS symbolic links. What I can see is that I still don't know. I can now see that there is much more I don't know: reparse points, file name records, unix security, etc, but I'm an application programmer, not a systems programmer, and I don't even know where to start (david)

The article claims NT has always supported symlinks, but they weren't available for use (except through POSIX) until fairly recently. My (probably shaky) recollection of the POSIX utilities in early versions of NT is that "ln" didn't support the "-s" option: it only created hard links. And Microsoft are currently claiming symlinks as a new feature of NTFS for Vista. Is there any evidence that symlinks aren't new? Reilly 22:21, 7 September 2006 (UTC)

NT 4 and 2000 are unable to create symlinks (only hardlinks), it appears in helen custer's book, and in NTFS' internal roadmap.

It is a new feature of Vista's NTFS

—Claunia 09:31, 9 September 2006 (UTC)

I've removed the bogus symlink claim from the article. The article also claims that Vista uses the same version of NTFS as XP and 2003. Is this false? Or are symbolic links implemented in a way that didn't require changing the on-disk structures? If so, how do symbolic links created in Vista appear if the disk is viewed in XP/2003? Reilly 19:55, 11 September 2006 (UTC)

I have not attempted to create symbolic links to files on Vista; however, the pre-installed symlinks (such as C:\Documents and Settings => C:\Users) are implemented in the same way as directory junctions on disk. 05:03, 20 December 2006 (UTC)

It changes on-disk structures but XP/2003 is still able to read/write that drives, but I have not checked how symbolic links appears.

—Claunia 07:58, 12 September 2006 (UTC)

Thanks. I found a plausible reference indicating that the NTFS version is indeed unchanged in Vista. Reilly 13:28, 12 September 2006 (UTC)

It seems plausable that NTFS 3/5 supports symbolic links, but that Windows 2000 did not. Clearly, nothing new will need to be added to NTFS: reparse points are already there. A reparse point would require a reparse filter. Win 2000 Win Explorer did not provide for the creation of symbolic links, but apparently they were mentioned in the NTFS SDK??? Perhaps they were defined but no reparse filter ever provided. (david) 218.214.18.240 14:38, 29 December 2006 (UTC)

Maximum length of filenames

The maxumum length of a filename is 255 characters in the root directory only. The value decreases with each folder level and the length of directory names within the path. So you never can move a file with a 255 character long filename into a folder.

If a file has reached the maximum filename length and you rename the folder having a longer name, you cannot delete the folder or rename the file (in Windows Explorer).

Taking this together, how can the statement "file system supports paths up to ca. 32,000 Unicode characters with each path component (directory or filename)" be true? --Sebastian 16:55, 19 Jun 2006 (MET DST)

Each path component can be up to 255 characters. At least, that's what the article says. So the value does not decrease with each folder level (at least, according to the article). And don't forget, just because Windows Explorer does not allow something, that does not necessarily speak to NTFS itself. Windows Explorer may impose additional restrictions just as the command line also does. --Yamla 15:11, 19 June 2006 (UTC)

I noticed that behaviour from ASP, not Explorer. But Explorer is the easiest way to reproduce this. I can't imagine that only ASP and Explorer show that behaviour. But maybe the Windows API is the cause... --Sebastian 13:18, 06 Jul 2006 (MET DST)

This is a problem that's becoming increasingly frustrating to me. My own experience is that you can't have pathnames longer than 259 characters (including the beginning X:\ and all the path separators ("\"), so maybe it's 256 characters excluding the leading drive letter, colon and separator). This limitation exists in a lot of programs (I don't know one where it doesn't exist), even though there is probably some way to access the data. I also think the statement "file system supports paths up to ca. 32,000 Unicode characters with each path component (directory or filename)" is completely misleading as most people will use the Windows implementation of NTFS where this just isn't normally possible (I tried it in Vista RC1 and it's still the same...). I wonder if it's an API issue, or if you could mount a different filesystem and get this to work... --85.224.6.48 06:40, 29 September 2006 (UTC)

I immediately tried mounting an Ext3 filesystem using the Ext2 Installable File System For Windows, created the exact same directory path and the result is the same. I haven't done much Win32 programming, but I guess something in the API is designed around limitations that don't exist today. Stone age. I'm very disappointed right now. --85.224.6.48 07:03, 29 September 2006 (UTC)

I have too much spare time (:. Just wrote a program that can access these long pathnames to prove that it can be done. Most programs are not written considering this limitation though, including Windows Explorer. --85.224.6.48 13:31, 29 September 2006 (UTC)

IIRC under windows if you want to use a pathname beyond a certain length you have to use an alternative file path style in the API calls. Needless to say few people do. 130.88.96.66 13:58, 21 May 2007 (UTC)

Active Directory+indexing?

"an interesting example is the addition of fields for indexing used by the Active Directory software" - huh? What does AD to do with NTFS? AD is saved in a Jet database. Indexing is something has nothing to do with ADS at all. Or have they mixed it up with the Alternate Data Streams? —The preceding unsigned comment was added by Lofote (talk • contribs) 21:39, July 11, 2006 (UTC)

Allowed characters in filenames?

I think it is somewhat misleading to say that all unicode characters except / are allowed in a NTFS filename. While that may be true about the core filesystem (although I am not sure about it), there are quite some characters which aren't allowed in a filename in most versions of Windows, and I think that those characters are what people search for and should be mentioned. I have no experience with editing Wikipedia, but if some of the more experienced members agree, I think that it is a good idea. —The preceding unsigned comment was added by 195.37.70.39 (talk • contribs) 08:24, July 17, 2006 (UTC)

This articale is about fisesystem, not filesystem realization in windows. NTFS itself support all utf-16 chars in filenames except '\0' and '/'. You can even create such filenames using ntfsmount or ntfs-3g in linux. In theory future versions of windows driver also may support them. —The preceding unsigned comment was added by 81.25.43.21 (talk • contribs) 17:39, October 13, 2006 (UTC)

Closed nature of NTFS

The - possibly stupid - question I have about NTFS that's not answered here is, "How on earth is a convicted monopolist like Microsoft allowed to keep the details of its main file system secret?"

The article mentions alternative ways of accessing NTFS, presumably developed by people reverse-engineering it, but why isn't Microsoft forced to publish sufficient info to write, say, a Linux driver?

Perhaps because the ability to manipulate NTFS is not required in order to interact with a Windows system. To my knowledge, the rulings against Microsoft have been about the ability of Microsoft to integrate other applications (e.g. Windows Media Player, Internet Explorer) more closely with Windows than their rivals could, by using "secret" APIs, not about the ability to replace Windows itself with another OS. If anyone wants their Windows application to access NTFS filesystems, they can use the public Windows APIs, so the issue doesn't arise.

Not that I'm unsympathetic to the moral case for forcing openness - like with the Office file formats, it would benefit everyone [except, possibly, MS] greatly if Microsoft did give up on its secrecy; but as far as I know, nobody has proven a legal reason why they should be forced to do so. - IMSoP 13:17, 21 September 2006 (UTC)

Hmm, but without the info, once you have a NTFS partition, you're tied into using Microsoft products or hoping that the people who've reverse-engineered it got it right, especially if you're trying to write to it. Plus it makes it 'difficult' for anyone else to write defragmenters or other low-level software. Lovingboth 18:53, 21 September 2006 (UTC)

Someone at least needs to add something like this under a critisism heading. The closed nature of this file system makes it a real bitch. The only defrag tool I can use is the windows defrag tool, which seems to do next to nothing. Linux kernel devs have been taking ages to try and figure out how the file system works, much to my annoyance, as to transfer files from other filesystems, I have to boot into XP and copy them across. Hell, why protect their filesystem as a trade secret? There seems to be way better ones out there, which are faster and open spec. I don't think anyone would use NTFS unless Windows offered it the only alternative to FAT. —The preceding unsigned comment was added by 202.10.86.59 (talk • contribs) 07:37, October 3, 2006 (UTC)

Adding this to the limitations section would basically be pushing a pro-open source, anti-commercial software agenda. Wikipedia is not the place to push your personal opinions. Besides, to say that no-one would use NTFS if there were alternative FSs would be to ignore the many features of NTFS, such as max volume/file sizes, ACLs, resource forks, extensible feature set, journaling, disk quotas, built-in encryption and more. Some of those features aren't even in the more popular Linux/Unix FSs. — EagleOne\^Talk 17:22, 13 October 2006 (UTC)

Not adding it would be pushing a pro-closed source, pro-commercial software agenda. The fact of the matter is, people criticize NTFS for it's secret nature- by definition, this makes it a criticism. Case and point- if one is setting up a shared network resource and must choose which FS to use, they will consider the advantages and disadvantages of each. One significant disadvantage of NTFS is lack of interoperability, due directly to its closed source nature- if one's network includes computers running Linux or OSX, lack of compatibility is a severe disadvantage that most other FS choices do not have. If thats not worthy of a "limitation", I don't know what is. 82.69.37.32 01:39, 27 April 2007 (UTC)

Networks transfer files over networks, and just don't care what the underlying file system is. There is no interop problem on networks. SchmuckyTheCat 02:11, 27 April 2007 (UTC)

UTF-16

NTFS is not UTF-16, see:

• https://www.siao2.com/2006/09/24/769540.aspx
• https://www.siao2.com/2006/09/10/748699.aspx

—The preceding unsigned comment was added by 137.189.4.1 (talk • contribs) 23:11, September 24, 2006 (UTC)

NTFS definition

OK, Alistair: Let's put a dispute tag on this, and let the community chime in.

Also, may I suggest you use www.Google.com, not www.Google.co.uk, as the results WILL differ. Discpad 23:41, 13 March 2007 (UTC) Dan Schwartz

Alistair and I are having a gentleman's disagreement over whether NTFS is the acronym for "Native Transactional File System" or "New Technology File System," so we'll put it out for comment by the rest of the community. {{subst:NTFSDiscussion|NTFS}} 23:47, 13 March 2007 (UTC)

No. Lets let the woman who was employed by Microsoft to write about the filesystem, who worked alongside the people who developed the filesystem, whose book was published by Microsoft decide. Page 1 of Helen Custer's "Inside the Windows NT File System" published by Microsoft Press: "The NT File System (NTFS) was created specifically..."

And Google.com makes zero difference: https://www.google.com/search?q=site%3Amicrosoft.com+%22native+transactional+file+system%22 AlistairMcMillan 23:48, 13 March 2007 (UTC)

So now you stopped calling it "New Technology File System?" Let's put this out for comment Discpad 23:53, 13 March 2007 (UTC)

Search for "New Technology File System" at microsoft.com and you will get results.[3]

Search for "NT File System" at microsoft.com and you will get results.[4]

Search for "Native Transactional File System" at microsoft.com and you get NO results.[5]

I'd be happy with either "NT" or "New Technology". AlistairMcMillan 23:57, 13 March 2007 (UTC)

Request for Comment: NTFS acronym

This is a dispute about what NTFS stands for. User:Discpad aka Dan Schwartz thinks it stands for "Native Transactional File System"? User:AlistairMcMillan thinks it stands for either "NT File System" or "New Technology File System". 00:30, 14 March 2007 (UTC)

Helen Custer's book was the best published reference I knew of when I spent two years reverse engineering NTFS. I had the distinct impression she was frequently side-by-side with the development engineers and probably wrote a lot more than the book contains, but details useful to write a filesystem driver for NTFS were systematically removed. As you all seem to know, she said it stood for New Technology File System.

Is that name lame? Yes. Should it have remained named that? No. (What would the next one be called?) Would microsoft rebrand what it stood for? Without hesitation. What should we call it? I suggest "New Technology File System" originally, later rebranded to XXX" if XXX can be cited. —EncMstr 00:34, 14 March 2007 (UTC)

I thought "New Technology File System" too, but if you check Helen's books you'll see that she always calls it "NT File System". AlistairMcMillan 00:52, 14 March 2007 (UTC)

Really? Must have been transitive logic from Windows NT#.27NT.27_designation. Alas, I no longer have a copy of the book. —EncMstr 00:58, 14 March 2007 (UTC)

Most Microsoft documentation, as well as reference books like Russinovich's Windows Internals, refer to it as the "NTFS file system". IIRC, it was originally an acronym for "New Technology File System", but by the time Windows 2000 rolled around, they were deemphasising the term "NT". "NT File System" was a term used in the NT4 timeframe (lots of old knowledge base articles use it, e.g.), but isn't used by Microsoft anymore. Nowadays it's apparently just "NTFS" with no spefiic acronym expansion. Given that "native transactional file system" returns single-digit result hits on both Google and WL Search, I'm pretty sure that hasn't ever been a correct term. -/- Warren 02:20, 14 March 2007 (UTC)

It's Native Transactional, not New Technology: It's a common mistake; and the name is derived from the transactional log used to self-repair (via unwinding) disk errors.

I think many of you are confusing the meaning of the "NT" in "Windows NT" which indeed is "New Technology" with the "NT" portion of "NTFS"... And I'll go with Sean Daily in Windows IT Pro: Windows NT 101 chapter in Optimizing Windows NT:
Installable file systems
Another portability feature of NT is its ability to support many different file systems. Currently, NT supports the FAT (File Allocation Table used in DOS, Windows 95, and OS/2 systems), NTFS (Native Transactional File System introduced with Windows NT), and CDFS (CD-ROM File System). However, because of NT’s modular nature, support for additional file systems can be easily added in the future by simply creating new file system drivers and adding them to NT. This makes it relatively easy for NT to incorporate new technologies. Dan Schwartz, Expresso@Snip.Net Discpad 03:34, 14 March 2007 (UTC)

It seems you've discredited Sean Daily: neither "New Transactional File System" nor "Native Transactional File System" appear anywhere on https://microsoft.com nor on https://msdn.com (according to Google), not even in a blog. After searching for all the variations of this, I'm more convinced it should be left as "NT File System", a new filesystem introduced with the operating system known as NT. —EncMstr 04:38, 14 March 2007 (UTC)

ARGGHHH! Please read the third paragraph of the Windows NT 101 chapter in Optimizing Windows NT Dan Schwartz Discpad 04:52, 14 March 2007 (UTC)

I read it. It does indeed say "Native Transactional File System". And? —EncMstr 04:58, 14 March 2007 (UTC)

Some guy wrote that term in a book, once, nine years ago. Big fucking deal. He could've invented the term in an effort to sound smart. Wouldn't be the first time that a tech writer did something like that. The fact that Microsoft introduced something called "Transactional NTFS" in Vista be a major clue-in that the T doesn't stand for Transactional. Just accept that Sean Daily is wrong, and move on. -/- Warren 12:08, 14 March 2007 (UTC)

Aside from this one book by Sean Daily and the many posts by yourself over many years are there any other sources? Did you originally get the "Native Transactional" version from this book? AlistairMcMillan 10:42, 14 March 2007 (UTC)

It was always my understanding that NTFS was not transactional, which is why Transactional NTFS[6] is a new feature of Vista, with a special new name. Mike1024 (t/c) 18:35, 18 March 2007 (UTC)

The arguments seem to distil down to, on the one hand:-

• Common knowledge says NT File System
• Helen Custer says NT File System
• No one disputes that NT stands for New Technology

...and on the other hand:-

• Sean Daily says Native Transactional (or perhaps New Transactional) File System
• microsoft.com and msdn.com do not mention these terms

...so, although I am loath to support arguments from Google as a matter of principle, it seems that NT has the stronger case - unless, of course, I have misunderstood someone's position. SheffieldSteel 21:14, 30 March 2007 (UTC)

Sorry if this comes across as a rather weak argument, but it is an argument nonetheless for the NT part of the acronym standing for the same thing it stands for in 'Windows NT', i.e. NT File System. My argument is based on what Google has archived of old Usenet postings. The earliest reference to NTFS appears to be in this posting. The post is by Alistair Banks, who, upon furthur google-based searching, appears to have been working in the Microsoft Systems Division at the time. I'm fairly certain that this user on Wikibooks is in fact the person who made the posting. In the post he wrote, 'NT File System (NTFS)'. This posting came long before the afforementioned book by Helen Cluster was published. Anyway, draw what conclusions you will from this argument, but I believe all the evidence suggests that NTFS stands for 'NT File System'. Johnnykimble 16:55, 9 April 2007 (UTC)

I agree that it's almost certainly NT File System as in "Windows NT", especially in light of the lack of reference to "new/native transactional" on the Microsoft site. Also, Johnnykimble makes a very valid argument for NT File System. --Dbackes 17:22, 24 April 2007 (UTC)

I'd say either NT File System or New Technology File System would be acceptable. Otherwise, Transactional NTFS would be redundant. —Remember the dot ^(talk) 02:46, 1 May 2007 (UTC)

Detail request

There is currently a line in the article, "Others: FreeBSD, eComStation and Mac OS X versions 10.3 and later offer read-only NTFS support. A free third-party tool for BeOS, which was based on NTFS-3G, allows full NTFS read and write. The read/write NTFS-3G driver has been also ported to FreeBSD, Mac OS X, NetBSD, Haiku and FreeDOS.". This, however, does not specify the name, creator, etc. of the third-party tool, or where it can be found. Could someone add it in? Does the tool have its own article? Thanks, samwaltz 01:20, 2 April 2007 (UTC)

Are you specifically asking about the BeOS port, because I think the article is being a little optimistic. Someone did announce that they'd started porting the NTFS-3G driver back in September last year, but at the time he qualified it as "highly experimental", and since then it hasn't been mentioned. AlistairMcMillan 02:00, 2 April 2007 (UTC)

If you are just asking about the NTFS-3G driver, we have a separate page here NTFS 3G. AlistairMcMillan 02:03, 2 April 2007 (UTC)