Talk:Filename

This article is rated B-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Software: Computing High‑importance This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. High This article has been rated as High-importance on the project's importance scale. This article is supported by WikiProject Computing (assessed as High-importance).

"File name" vs "Filename"

Should filename be one or two words? There seem to be no strict convention; google finds 20M pages containing "file name" and 30M pages containing "filename". This indicates that "filename" is a slightly better choice, but still, over 400 articles in wikipedia contain the subword "file name". How is it possible to know which variant to consider correct? Who decides? --Erik 17:08, 8 December 2005 (UTC)[reply]

I've seen it both ways. I think that generally "filename" should be used when discussing the name entity itself (e.g., "this filename and that filename"), while "file name" should be used when discussing different types of names (e.g., "file names and directory names"). — Loadmaster 16:22, 2 September 2006 (UTC)[reply]

Disagree. Be consistent. Two words. Stevebroshar (talk) 16:49, 27 September 2025 (UTC)[reply]

The article contains a mix of "file name" and "filename" right now. I would propose to change it to "filename" everywhere, excepted in cases where different types of names or discussed, as Loadmaster says above.83.78.62.69 (talk) 13:22, 7 February 2008 (UTC)[reply]

"Compounds are written in 3 ways: solid (as cottonmouth), hyphenated (as player-manager), or open (as field day)." -- Webster's Compact Writers Guide (printed version). "filename" is styled solid; "file name" is styled open

Search for "filename" succeeded:

1. http://www.thefreedictionary.com - lists "filename" and "file name"

2. http://www.techdictionary.com - lists "filename extension" and "file name"

3. http://www.wordwebonline.com - entries for "filename" and "file name"

4. http://wordnet.princeton.edu/ - contains "filename" and "file name"

5. http://www.computer-dictionary-online.org - entry for "Filename extension", entry uses "filename" as a noun in isolation

6. Microsoft Style Guide - reportedly suggest "filename" (http://www.techwr-l.com/archives/9610/techwhirl-9610-00718.html)

7. Microsoft Word 2002 spell checker accepts "filename" by default

8. Google-search for "define: filename" yields multiple results (http://www.google.com/search?hl=en&q=define%3A+filename&aq=f&oq=&aqi=g10)

9. Wikipedia - lists "filename" and "Fully qualified file name"

Search for "filename" failed:

1. www.merriam-webster.com - "filename" is NOT listed

2. "file name" is used in The Chicago Manual of Style Online (a search for "filename" yielded 0 results)

"The trend toward closed compounds : With frequent use, open or hyphenated compounds tend to become closed (on line to on-line to online). Chicago’s general adherence to Webster does not preclude occasional exceptions when the closed spellings have become widely accepted, pronunciation and readability are not at stake, and keystrokes can be saved. " -- The Chicago Manual of Style Online

"Filename" is certainly widely-accepted; readability is certainly not a problem; and a keystroke is saved...yet they use "file name" in their own writings.

I would suggest "filename" be used since it is widely-accepted (e.g., 1-8 above), readable and saves a single keystroke (which also yields a faster reading of the word).

Note: Username v.s. "user name" is similar. "Username" does not appear in www.merriam-webster.com; but is used ubiquitously in the "Wikipedia:Username policy".

Pediaguy (talk) 20:01, 20 June 2009 (UTC)[reply]

Username is more techno babble. Stevebroshar (talk) 16:48, 27 September 2025 (UTC)[reply]

Wikipedia's own Manual of Style (http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style) does not comment on "filename" versus "file name" directly, but "filename" is the only form used throughout the text. Pediaguy (talk) 20:40, 20 June 2009 (UTC)[reply]

But which form _should_ be used? That it uses one style has no bearing on whether it's a good choice. Stevebroshar (talk) 16:48, 27 September 2025 (UTC)[reply]

In addition, using filename prevents the seperate words from being broken across a line (or worse a page) DGerman (talk) 00:13, 24 April 2012 (UTC)[reply]

Non-issue. Words are supposed to wrap when they have a space between them ;) Stevebroshar (talk) 16:46, 27 September 2025 (UTC)[reply]

Here's the difference: 'filename' is techno babble (what nerds say... I know being a nerd myself). 'file name' is what normal humans use. Stevebroshar (talk) 16:46, 27 September 2025 (UTC)[reply]

Does filename and file name have the same meaning?

I mean for my understanding, a file name is a name, as such, it is a text, from a user perspective. Filename is a sequence of byte at least under unix like system, from a developer perspective. If so it a difference which should be considered? Doesn't it? — Preceding unsigned comment added by 79.80.139.130 (talk) 20:40, 24 August 2012 (UTC)[reply]

Important stuff 71.57.3.113 (talk) 04:50, 15 January 2025 (UTC)[reply]

I see no difference. It's text, yes. It's a sequence of bytes, yes, that's what text is. Well, text is bytes that encode per an encoding. But, I see only one thing. As to whether you call it 'filename' or 'file name' is a different matter. But... I think you're approaching the key aspect of the difference between the two spellings. 'filename' is techy and 'file name' is genpop. Stevebroshar (talk) 16:44, 27 September 2025 (UTC)[reply]

Possible inaccuracies

The table currently states that a DOS filename has up to 12 characters. Surely 11. The stop or period separating the primary filename from its extension isn't an actual part of the filename.

UNIX is said to allow filenames of up to 255 or 256 characters. This hasn't always been the case, has it? It would be a good idea to distinguish by UNIX version number, as the table does with Mac and Windows versions. I think UNIX used to have a much smaller limit (somewhere between 12 and 20).-86.134.90.94 20:25, 11 April 2006 (UTC)[reply]

The original Unix allowed filenames of 14 characters. This allowed directory files to be arrays of 16-byte entries, the first 14 bytes being the filename and the last two being the inode number. — Loadmaster 22:46, 2 May 2007 (UTC)[reply]

"In some operating systems, such as MS-DOS, Microsoft Windows ... upper-case letters and lower-case letters in file names are considered the same, so that, for example, the file names "MyName" and "myname" would be considered the same, and a directory could not contain a file with the name "MyName" and another file with the name "myname"." - this is not totally accurate. NTFS is case sensitive with regard to filenames so a single folder could contain MyName and myname even if some (most?) Windows applications may have problems dealing with filenames differing only by case. —Preceding unsigned comment added by 62.17.140.34 (talk) 15:11, 11 April 2008 (UTC)[reply]

At Least Windows Explorer in Windows XP doesn't allow the creation of a file, if there is already another file in the folder which is only different in case, not even on NTFS partitions. So i.E. if you already have a file with the name MyName in some folder, you cannot create a file named myname. --MrBurns (talk) 23:58, 13 November 2008 (UTC)[reply]

NTFS does allow for, say, MyName.txt and myname.txt to exist simultaneously - see here for more info: http://support.microsoft.com/kb/100625

A file system utility restriction, not a filesystem restriction DG12 (talk) 03:31, 3 August 2011 (UTC)[reply]

The Wikipedia article on ISO_9960 mentions several limitations on path length for a file name. The latest update, ISO 9960:1999 has a limit of 207 characters.DrHatch (talk) 18:24, 23 January 2010 (UTC)[reply]

The table claims that Amiga SFS supports filename length of 32,000? This seems frankly unbelievable, and the page on SFS claims the limit is only 107 characters. Is there any corroboration on this? 130.156.141.3 (talk) 20:49, 6 November 2012 (UTC)[reply]

This is still a problem in 2017. --NoToleranceForIntolerance (talk) 08:49, 20 June 2017 (UTC)[reply]

Forward slash (/) on Windows

Shouldn't the forward slash on windows be included, because when I create a file I cannot create one with a forward slash. And windows (2000) response with: "A filename cannot contain any of the following characters: \/:*?"<>|

I added the forward slash, and the pipe (both were already included, but not displayed).

I had to change pipe into HTML #124, and put the Slash at the end.

Both appear now correctly (I only edited the Win95 and winXP entries: please someone check also the DOS and FAT sections?)

82.196.52.11 16:42, 28 August 2006 (UTC) olivier Dulac[reply]

The reason given for the forward slash being reserved in MSDOS/Windows is not quite correct. The '/' character is not valid for use as a path separator, it is used to denote command-line switches. For example, on Windows, dir temp/b will list everything in the temp directory and use the /b (bare listing) switch, rather than listing a file or directory called temp\b. Probably also need to edit the description for '\' if you change this. CupawnTae 11:40, 21 September 2007 (UTC)[reply]

This is not quite true either. The forward slash is supported as a path separator in all internal API calls. It's just not supported in many command line utilities, including basically all those supplied with the operating system. API calls such as CreateDirectory() work perfectly well with forward slash, but since it's one of the two valid separators (with backslash) it is not allowed in filenames. Really, the original description is technically quite correct. PeterHansen 16:21, 26 September 2007 (UTC)[reply]

And if the SwitChar is changed from its default '/' to '-', all properly written tools will also accept the '/' as a path separator. --Matthiaspaul (talk) 12:16, 2 June 2014 (UTC)[reply]

Other File Systems

The article contains no mention of non-Unix filesystems. It would be nice if it included mention of historical systems (e.g., DEC RSX-11) and ISO 9660 CD naming conventions.
— Loadmaster 20:25, 3 September 2006 (UTC)[reply]

For information on various file systems, Unix and non-Unix, see Comparison of file systems, which mentions both Files-11 ODS-2 and ODS-5. The section giving file system details was somewhat incomplete - Comparison of file systems was more complete - and a bit confused for various reasons, including mixing up operating systems naming rules and file system naming rules (which aren't necessarily the same - a given file system might support names that an OS on which you're using it doesn't, and an OS might support names that a particular file system it can use doesn't). I got rid of that section. Guy Harris 03:34, 28 October 2006 (UTC)[reply]

Filename is not URL etc.

I find the explanation of filename very confusing. Argument: I think a filename should be unambiguous.

Protocol can be various, multiple names for the same file ? No protocol in filename then.

Host can be various, so ? No host in filename.

Device can be various, so ? No device in filename.

Directory can be various, so ? No directory in filename.

File can be various, why ? File indecates contents, sort of something you can actualy grap, you can not put contents in the name.

Type can be various, what ??!! Well, this extension use for identifying a file's type is more something used by MicroSoft. It can be done that way, but is not necessary, UNIX and derivates mostly use contents and flags to define the explecit file-type, so ?? no type in the name.

Version can be various, so ? No version in filename. You can, of course, code a filename as having a version number but that is not at all necessary.

I think the explanation of "filename" could be very compact and clear:

filename is the name of the entity file !

name, entity and computer file are explained on other pages. The rest of the article is nice as it explaines some of the issues one can encounter on specific computer environments. (80.156.47.238 (talk) 10:23, 24 April 2008 (UTC))[reply]

Confusion between 'filename' as a fully qualified (unique) name, a name for a file within a directory, or both

This article is confusing when it comes to trying to determine if a filename is the name of a file within a directory or not.

On the one hand, it seems to suggest that a filename is the 'fully qualified filename', containing the full path, up to the access protocol. On the other hand, it talks at the bottom about length of filenames, with the length being limited to 8 + 3, or 255, which clearly only applies to the name of a file within a directory.

This article should be cleaned up with that in mind, inventing or reusing clearly defined words for filename, filepath, ... —Preceding unsigned comment added by ThomasVanderStichele (talk • contribs) 12:33, 11 November 2008 (UTC)[reply]

I have used filename, filepath, foldername and folderpath in Java/C# code. Natural language variants depend on compound word styling conventions, so I list these compound words with solid style to sidestep that issue. These 4 terms are symmetric, cover all typical cases and have a 1:1 mapping when used strictly. Examples (for Windows):
filename="file.txt"
filepath="C:\work\temp\file.txt"
foldername="temp"
folderpath="C:\work\temp"

Pediaguy (talk) 20:13, 20 June 2009 (UTC)[reply]

I added a discussion of this to the article opening. It is unfortunate, but it is certainly not the job of Wikipedia to define a specific meaning of "filename". But this leads to ambiguity in the article because individual authors simply talk about whatever aspect of a filename suits them especially e.g. in talk of length limits. Notice for example the talk of the length limit in FAT16 as being "11" because there is an 8 character base and 3 character extension. However, as almost all users see this a name containing a dot, they see a name of 12 characters. Really the length section needs doing again with a detailed discussion of what is meant. 31.48.253.151 (talk) 11:34, 13 June 2014 (UTC)[reply]

8.3 filenames

8.3 filenames can contain all ASCII-characters (including the characters 0x80-0xFF), except those characters which are reserved for special purposes. these characters are not allowed. They are 0x00-0x1F, SPACE, DEL, " * / : < > ? \ | --MrBurns (talk) 00:03, 14 November 2008 (UTC)[reply]

SPACE always was a valid filename character in the FAT filesystem. However, since it is also a parameter separator, it was difficult to create files and directories including spaces (except for filler-spaces). Typically, this only worked with commands accepting a single parameter only, like with MK or RD.

The following additional characters are also not allowed for short filenames: + , . ; = [ ] (but they are allowed for LFNs with VFAT).

0xE5 was not a valid character for the first letter in a filename under 86-DOS, and MS-DOS/PC DOS 1.x-2.x, but is in higher versions. This was done to suppport alternative codepages since DOS 3.0. A special "hack" was implemented for this, which stores 0xE5 as 0x05 in the file system.

";" is also a separator for file and directory passwords in DRI operating systems. 4DOS uses it for include lists but allows it to be doubled for passwords. DR-DOS 7.02 and higher will accept a doubled semicolon also on API level, so that users can use doubled semicolons for passwords regardless if they are filtered on application level or in the kernel.

In addition to this, DR-DOS and 4DOS use "@" for filelists. While it is still a valid character in the underlying filesystem, it is difficult to enter as such.

Finally, "!" is a multiple command separator in Multiuser DOS (and DR-DOS internally) and therefore difficult to use in filenames (except for in LFNs).

--Matthiaspaul (talk) 12:36, 2 June 2014 (UTC)[reply]

File system versus WIN32 API

At lot of the assertions about what "Windows" permits are superficially true at the user level, but not at the file system level. For example, the prohibition about not having a dot at the end of the name is not actually a prohibition as FAT as NTFS or the kernel are concerned, and if you know the right incantations, you can create such a name.

That particular prohibition arises from FAT history. Since the (one and only) dot in pre-longname FAT was not actually stored on disk, but was merely a syntactic marker in the API, it was not possible to distinguish "FOO." and "FOO"; either way, the 8-byte name field contained "FOO " and the 3-byte extension field contained " ".

The file system and NT kernel had no need of such nonsense, and in fact the original goal of a multiple-personality OS (and the requirements for POSIX conformance) argued against it. In what to my mind was a misguided fit of compatibility with old crap, the Win32 layer implemented DOS-like restrictions. —Preceding unsigned comment added by 70.88.209.29 (talk) 18:58, 9 March 2009 (UTC)[reply]

Reserved characters and words mostly wrong

The article confuses shell behavior with filesystem specifications. It should be discussing what a filename is, where it came from historically, its encoding, how it differs from the file. What /bin/sh or cmd.exe do with files, or how they manage redirection, are absolutely beside the point.

In Unix, regardless of filesystem type, a filename is binary character string. The only invalid characters are '/' and NUL, a binary zero. Cf. Dave Wheeler's discussion.

$ touch '\?%*:|"<>.....txt' && ls -l *.txt
-rw-rw-r-- 1 dante abcd 0 Mar 11 13:41 \?%*:|"<>.....txt
$ file \\\?%\*\:\|\"\<\>.....txt 
\?%*:|"<>.....txt: empty

Even control characters such as tab, backspace, and newline are valid.

In any case, the valid set of characters -- even what constitutes a character -- is a function of the filesystem and, to a lesser extent, the operating system.

--Jklowden (talk) 18:57, 11 March 2010 (UTC)[reply]

This can be discussed:

From my understanding,

• Technical things — file systems — provides code unit strings known as filenames (one word).
• The user known textual strings known as file names (two words), made of characters.
• The OS makes the glue by storing a configuration which tell which encoding is used on which file system, providing required connection between characters and coed units. 86.75.160.141 (talk) 23:03, 6 November 2012 (UTC)[reply]

The "Problematic characters" subsection draws a distinction between "not allowed by the file system or the file system code" and "allowed by the file system and the file system code, but requires special handling on, for example, the command line". Guy Harris (talk) 20:45, 7 April 2024 (UTC)[reply]

The section "Problematic characters" has several references to "CMD.EXE on DOS and Windows." for example comma, semicolon, equals. Should these include unix like file systems? — Preceding unsigned comment added by DGerman (talk • contribs) 12:21, 7 April 2024 (UTC)[reply]

More like "Unix command-line interpreters". That table says of the semicolon that it's "Allowed, but treated as separator by the command line interpreters COMMAND.COM and CMD.EXE on DOS and Windows." It should say the same about the command-line interpreters the Bourne shell (and compatibles, such as the KornShell and bash) and the C shell (and compatibles, such as tcsh).

I'm not sure what the problem is with Unix shells and comma and equals, however:

   $ echo comma >foo,bar
   $ cat foo,bar
   comma
   $ echo equals >foo=bar
   $ cat foo=bar
   equals

I'll expand the section on semicolon. Guy Harris (talk) 20:15, 7 April 2024 (UTC)[reply]

Merge Proposal

There has been a proposed merge with Fully qualified file name for years; I think these articles are sufficiently different to keep as-is. I am removing the merge tag. Jminthorne (talk) 05:58, 25 April 2010 (UTC)[reply]

Meaning of basename

In the article, the term "basename" is used to mean the name of a file without any trailing extension. In POSIX systems, the term "basename" refers to a command or function returning the name of a file without any leading path component (see [1]), so the basename of "foo/bar/baz.txt" is "baz.txt" (and not "baz"). This is also consistent with PHP ([2]), Ruby [3], Python ([4], note also how "os.path.split() is defined), Visual Basic inside Microsoft Word 2003 ([5]) and so on.

Also note that the source cited in the article uses the expression "base file name" (and not "basename"). -- IANEZZ  (talk) 18:40, 3 July 2010 (UTC)[reply]

protocol and port are not part of file name

Individual files can be accessed be different protocols and ports and are not part of a filename. DG12 (talk) 14:29, 3 August 2011 (UTC)[reply]

filename as an entity in a filesystem verses as used in a command or API

There are many inaccuracies in this article which relate to the difference between the string of characters in a filesystem structure(its name) and reference to a file.

For example regarding components, a directory contains filenames (and may contain other directory names) but the directory in which a file is located is not part of the file name.

The reference to filenames "." and ".." have special meanings, there are not actually files named dot and dotdot rather these are command syntax means to reference particularly directories.

The same issue (which has been mentioned previously in this talk page) it true regarding which characters can be included in a filename. For example a slash character IS permitted in a filename, although references to a file containing a slash must be treated specially to avoid the interpretation as a directory reference.

I await responses to these comments before reworking much of this page.

Sincerely, DGerman (talk) 00:12, 24 April 2012 (UTC)[reply]

For dot and dot dot I do not agree with you (see next link), althouth this might be system dependant.

http://140.120.7.20/LinuxKernel/LinuxKernel/node17.html

For the rest of the article, there might be confusion and this confusion mlght come that everibodi does not use same convention. — Preceding unsigned comment added by 86.75.160.141 (talk) 20:45, 9 October 2012 (UTC)[reply]

Dot and dot dot are not handled purely at the command line; they are handled specially below the file system API layer, and most code at the user layer does not treat them specially. That's true on all UN*Xes; it's not system-dependent.

What is filesystem-dependent is whether there really are files with those names or not. In the file system on Version 6 Unix and Version 7 Unix, and in the Berkeley Fast File System, "." is a hard link in every directory that has the inode number of that directory (i.e., it's a hard link to itself), and ".." is a hard link in every directory that has the inode number of the parent directory of that directory (i.e., it's a hard link to the parent), except in the root directory, where it's a hard link to itself, with the pathname parsing code in the kernel special-casing it for file systems mounted on a mount point other than "/" so that it goes to the parent of the mount point. Some file systems used on UN*X systems don't have them in the file system on storage, and treat them specially in the file system code (I think that might have been true for HFS+, for example).

Slash is also not handled purely at the command line; the file system APIs are handed path names, and treat / as a pathname separator at that layer. The on-disk structure of UN*X file systems theoretically allow a file name in a directory to contain a "/", but there's no way to do that using any UN*X file system API, nor is there a way, using any UN*X file system API, to open/rename/remove/etc. such a file.

One file system that does allow file names on disk to contain / is HFS+. That's because it was originally designed for use in the classic Mac OS, which used a colon as a path name separator; again, theoretically, a file name on an HFS+ volume could contain a ":", but I don't think the classic Mac OS APIs would allow that to happen, and they might have made it difficult if not impossible to access, remove, or rename such a file.

To allow a single HFS+ file system to be used both by the classic Mac OS and macOS, the macOS HFS+ file system code, when asked to create or refer to a file by name, would map all colons in the file name to slashes and, when asked to show the names of files in a directory, map all the slashes in the file name to colons. Thus, if a user created a file named "I/O performance study" on the classic Mac OS, it would, from the UN*X API layer and, thus, on the command line, have the name "I:O performance study".

However, in macOS, the Finder, and the Carbon and Cocoa API layers do their own mapping, independent of the underlying file system, to present a file system view that looks more like the classic Mac OS view, so that the file that has, at the UN*X layer, the name "I:O performance study" will appear to have the name "I/O performance study" from the GUI, and files with slashes in their names can be created but files with colons in their names cannot be created. Guy Harris (talk) 21:17, 7 April 2024 (UTC)[reply]

There IS a built-in tool to maintain hard links in Windows XP

The article cites [1] to claim that no Windows version before Windows Vista has a tool to create hard links. This is wrong for two reasons. First, the page does not mention Windows Vista but instead states that beginning Windows 7 the mklink tool is provided. Second, that page is absolutlely wrong with this assertion because in Windows XP there is the built-in tool fsutil which can be used to create and delete (at least) hard links. The writer of this sentence in the article should have informed him-/herself better before citing a wrong source (using a single source is never a good idea). — Preceding unsigned comment added by Sixot (talk • contribs) 13:06, 17 May 2012 (UTC)[reply]

length in bytes or characters?

The table in the section called

Comparison of filename limitations

has a column called "Maximum length". I would suggest to improve this information and specify whether the length is counted in bytes or in characters. — Preceding unsigned comment added by 2001:6B0:E:2018:0:0:0:207 (talk) 00:09, 3 October 2012 (UTC)[reply]

Not sure how pertinent unit is character, as NTFS is 16 bits based (ie double octet). When some characters need several code units (case of surrogates in utf-16) or several code points (NFD decomposition form).

This is why I suggest as unit: octet code unit, and double octet code unit.≈≈≈≈86.75.160.141 (talk) 20:29, 9 October 2012 (UTC)[reply]

Épône - Parking Gare01.jpg

Photo whose filename is “Épône - Parking Gare01.jpg”, based on the name of the city: Épône

While the picture might be irrelevant to illustrate article, the filename is an example of real filename as it can appear on the english wikipedia. So I suggest to not include picture, but to add a sentence like: but to add a sentence like:

• Users tend to include diactrics characters and spaces in file names, as in regular names. For instance one of the pictures which illustrates the Wikipedia articles (on Épône and Parking) is named: "Épône - Parking Gare01.jpg". — Preceding unsigned comment added by 86.75.160.141 (talk) 21:33, 5 November 2012 (UTC)[reply]

Virus authors

"Nobody should want to use a bytes sequence which does not match any kind of character as this would result in a non displayable filename." - well virus authors do — Preceding unsigned comment added by 150.140.47.56 (talk) 13:15, 12 July 2013 (UTC)[reply]

You raise two questions:

1. Why virus author do, and why people need virus?
2. Might be Nobody here means no regular user. — Preceding unsigned comment added by 77.193.107.123 (talk) 21:40, 23 January 2015 (UTC)[reply]

Edit war over ==Usage==

In this edit 77.193.112.209 reinstated a removed section. I reverted that, because the content was unsourced and not written well. Wikipedia articles are not playgrounds for throwing up some text to see if it will stick - it won't. In my opinion the content merits improvement and citing, and that process should occur here, in Talk. So here it is:

==Usage==
System offer a wide choice of characters and bytes to compose filenames. 
About any unicode character or byte can theoricaly be used.

It is technically possible to use a bytes sequence which does not match 
any kind of character, but this would result in a non displayable filename 
and is useless for the user. In the same way, technically control characters 
could be inserted inside a filename, while this is useless. Nonetheless, this 
might be used for instanceby viruses.

A convenient and usefull filename is a filename which has a readable signification, 
for instance being composed of a sequence of few words.

Additionally, to ensure interoperabilty, a filename will be usable in most systems, 
and workaround system deficiencies, some users use only some subset of possible 
characters for file exchange. This subset might be, for instance, ASCII.

Discuss? --Lexein (talk) 20:47, 29 August 2013 (UTC)[reply]

Due to issues in files attached within electronic mail, might be this extract of rfc6266 (http://tools.ietf.org/html/rfc6266) might be taken into account?

« Recipients SHOULD strip or replace character sequences that are known to cause confusion both in user interfaces and in filenames, such as control characters and leading and trailing whitespace.

Other aspects recipients need to be aware of are names that have a special meaning in the file system or in shell commands, such as "." and "..", "~", "|", and also device names. Recipients SHOULD ignore or substitute names like these.» — Preceding unsigned comment added by 77.193.112.209 (talk) 12:02, 29 September 2013 (UTC)[reply]

NTFS Length Restriction

The NTFS length restriction is actually not by the filesystem. Its by the file system handler, NTFS supports paths of up to ~32,000. The 255 are defined by MAX_PATH. You can test it for yourself, create a folder with a total path length of around 230. Then create a folder inside it with only like 5 chars. Create a network share for the small folder. Now you can put another 255-foldername inside there if you access the share over the network. And it will still work. Only localy you will have issues accessing it. But the Filesystem can handle it. --217.151.145.186 (talk) 09:54, 20 July 2015 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on Filename. 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:

• Corrected formatting/usage for http://developers.sun.com/global/products_platforms/solaris/reference/presentations/IUC29-FileSystems.pdf
• Added archive https://web.archive.org/20110315014244/http://kerneltrap.org:80/mailarchive/git/2008/1/23/593749/thread to http://kerneltrap.org/mailarchive/git/2008/1/23/593749/thread

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

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) 20:54, 20 July 2016 (UTC)[reply]

File Extensions

The way filetypes, extensions and versions are described is misleading.

File Systems like FAT itself do neither "allow" nor prohibit file extensions. At this level extensions are not interpreted or recognized in any way, they are just some more characters in the filename. The filesystem just stores data under a name, no mattter what type of data it is, as its all just bytes at this level anyway.

Applications and some system functions try to guess the filecontents by interpreting the last part of the filename after the dot, but for the filesystem itself this is meaningless.

"file – base name of the file" WHAT?????

Is it a joke? — Preceding unsigned comment added by 91.122.13.59 (talk) 18:20, 15 September 2019 (UTC)[reply]

I don't think it's a joke but an undefined term which confused me enough to want to comment here and ask someone to clarify. Is a base name the part of the filename without a path or extension? Or something else? Chimla (talk) 21:28, 27 October 2021 (UTC)[reply]

FYI:

There is a *nix command base name which takes a URL (which may include protocol, host, directory,.. filename, extension ) and

"deletes any prefix ending with the last slash `/' with -s a suffix can be specified which will be removed.

dirname outputs the prefix characters omitted .

Examples:

basename http:///Volumes/Rx/ruuvi.firmware.c.emProject.220227.txt

ruuvi.firmware.c.emProject.220227.txt

basename -s txt http:///Volumes/Rx/ruuvi.firmware.c.emProject.220227.txt

ruuvi.firmware.c.emProject.220227.

dirname http:///Volumes/Rx/ruuvi.firmware.c.emProject.220227.txt

http:///Volumes/Rx DGerman (talk) 15:28, 20 April 2022 (UTC)[reply]

Why is the straight double quotation mark reserved in Windows?

In this edit to Filename § Reserved characters and words, included in the "Windows" subsection, I set out to note that some quotation marks are not reserved characters. I was editing the "Reason for prohibition" column, adding some permissible characters. Of course, I wasn't really addressing reasons for prohibition, but prior editors have used the column for this purpose and I felt justified in following their lead.

Already in the column was a note that the character " is used "to mark beginning and end of filenames containing spaces in Windows". Hold on, I thought — as " is not a permitted character in a filename, there's no way it can be included to mark its beginning and its end. (Even if it could be, this would not provide a reason for prohibition, any more than my intended edits do.) I accordingly deleted that claim, leaving my addition — which also doesn't provide a reason — as the only thing left in the column.

Somebody please explain: Why is the straight double quotation mark prohibited in Windows? Every other list item provides an intelligible reason.

Peter Brown (talk) 00:59, 10 September 2020 (UTC)[reply]

My understanding is that it's a legacy restriction carried over from DOS. Specifically:

• DOS aimed for easy portability of applications from CP/M. Because of that, command-line arguments in DOS weren't passed to a program as a pre-tokenized argv array like in UNIX but, instead, as a raw string in a metadata structure called the Program Segment Prefix which resembles CP/M's Zero Page.
• The command-line parsing rules used by DOS programs are baked into each program... typically as part of the C/C++ runtime's code for filling out argc and argv.
• Those parsers had no means of quoting characters with special meanings, aside from wrapping the argument in double quotes.
• While Windows's CreateProcess (which still takes a string like its ancestors instead of an argv) did implement one specific escape (\" is interpreted as a literal double quote unless the \ is the trailing character of \\ but all other uses of \ are still literal and all other uses of " are still metacharacters), the rules for filenames are still geared toward staying compatible with old programs embedding old old command-line tokenizers.

I know at least some parsers had already solved that in the DOS era in an SQL-ish manner by interpreting "" as a literal ", but don't ask me how common it was.

--Deitarion (talk) 10:51, 6 December 2020 (UTC)[reply]

illegal and under-documented sequence: folders starting with @ symbol and containing 2 numbers delimited by a comma

try creating a folder and naming it something like this: "@ thisname 100,200 installowed" it doesn't matter what else goes into the name, if it begins with @ and has 2 numbers separated by a comma with no space in between, it will silently fail to name the folder.

not sure why this is, but it's still an issue in Windows 10 64-bit running on NTFS, and after an extensive search I couldn't find any documentation, explanation, or even other mention of it on google.

This is peculiar to MS Windows file system as apple's AFS allows exactly that

-rw-------    1 30010 Apr 30 17:43 .zsh_history
drwx------   50  1600 Apr 30 18:04 .zsh_sessions/
-rw-r--r--    1     0 Apr 30 18:04 @ thisname 100,200 installowed
drwxr-x---+  71  2272 Apr 30 18:04 ./

DGerman (talk) 22:12, 30 April 2022 (UTC)[reply]

Works when saving via Notepad. Must be triggering some operation in the Shell, but we won't know for certain without an external source that's decoded it. Searching for @ seems to be impossible, and Event Viewer shows nothing, so unless someone comes out or decompiles the Shell, it'll remain a mystery for the ages.

Wiimeiser (talk) 14:49, 10 March 2024 (UTC)[reply]

Question Mark and Period in Modern Windows

Recent versions of Windows appear to have changed "?" to behave exactly like "*", causing it to return all filenames in the folder and all subfolders, instead of just returning filenames with exactly one character.

Additionally, Windows programs other than Windows Explorer are unable to load files beginning with a period/dot. This goes so far as being unable to delete such files, with the shell locking up if it tries to delete such a file that's been zipped.

Both of these might be notable enough, though I'm not sure. Wiimeiser (talk) 14:41, 10 March 2024 (UTC)[reply]

I don't know how recent "recent" is required to be, but, at least in Windows 11 23H2 build 22631.3007, neither of those appear to be true from the cmd.exe command line with the copy and type commands:

   C:\Users\gharris>copy con: .hello.txt
   Hello, world!
   ^Z
           1 file(s) copied.
   
   C:\Users\gharris>type .hello.txt
   Hello, world!
   
   C:\Users\gharris>copy con: .h.txt
   H!
   ^Z
           1 file(s) copied.
   
   C:\Users\gharris>dir .?.txt
    Volume in drive C has no label.
    Volume Serial Number is 3029-FAAD
   
    Directory of C:\Users\gharris
   
   04/07/2024  04:11 AM                 4 .h.txt
                  1 File(s)              4 bytes
                  0 Dir(s)  146,198,331,392 bytes free
   
   C:\Users\gharris>dir .*.txt
    Volume in drive C has no label.
    Volume Serial Number is 3029-FAAD
   
    Directory of C:\Users\gharris
   
   04/07/2024  04:11 AM                 4 .h.txt
   04/07/2024  04:10 AM                15 .hello.txt
                  2 File(s)             19 bytes
                  0 Dir(s)  146,199,445,504 bytes free
   
   C:\Users\gharris>del .h.txt
   
   C:\Users\gharris>del .hello.txt
   
   C:\Users\gharris>dir .*.txt
    Volume in drive C has no label.
    Volume Serial Number is 3029-FAAD
   
    Directory of C:\Users\gharris
   
   File Not Found
   
   C:\Users\gharris>dir *.txt
    Volume in drive C has no label.
    Volume Serial Number is 3029-FAAD
   
    Directory of C:\Users\gharris
   
   File Not Found

In which version of Windows, and in which programs, are you seeing those behaviors? Guy Harris (talk) 11:22, 7 April 2024 (UTC)[reply]

Unchanged as of 23H2 build 22631.3296, right after an update. Guy Harris (talk) 19:35, 7 April 2024 (UTC)[reply]

Generation Data Group IBM GDG

Can/should someone add a paragraph explaining IBM GDG. Perhaps a distillation of [6]https://www.ibm.com/docs/en/zos-basic-skills?topic=vtoc-what-is-generation-data-group DGerman (talk) 12:06, 7 April 2024 (UTC)[reply]

Or a paragraph about filenames with versions, in general; Files-11 has version numbers for all files, so it's as if every file belongs to the equivalent of a GDG. Guy Harris (talk) 19:45, 7 April 2024 (UTC)[reply]

And maybe you would be the "Guy" to add it. :-) DGerman (talk) 00:36, 8 April 2024 (UTC)[reply]

OS/360 and VM/CMS

The OS/360 on dots and eight characters is only for cataloged files. Many system files are required to be cataloged, though. Yes for CMS the TEXT filetype is technically for TEXT files, but what CMS calls TEXT, everyone else calls object files. I don't know that there is a CMS filetype for what Unix and DOS call .txt files. CMS also has TXTLIB for object libraries. Gah4 (talk) 21:36, 12 May 2025 (UTC)[reply]

So, according to VTOC § Format 1 DSCB, the first field of a DSCB in the VTOC is a 44-character dataset name.

OS Data Management Services Guide Release 21.7 says, in "Data Set Identification" on page 3:

Whenever you indicate that a new data set is to be created and placed on auxiliary storage, you (or the operating system) must give the data set a name. The data set name identifies a group of records as a data set. All data sets recognized by name (referred to without volume identification) and all data sets residing on a given volume must be distinguished from one another by unique names. To assist in this, the system provides a means of qualifying data set names.

A data set name is one simple name or a series of simple names joined together so that each represents a level of qualification. For example, the data set name DEPT58.SMITH.DATA3 is composed of three simple names. Proceeding from the left, each simple name is a category within which the next simple name is a subcategory.

Each simple name consists of from 1 to 8 alphameric cbaracters, the first of which must be alphabetic. The special character period (.) separates simple names from each other. Including all simple names and periods, the length of the data set name must not exceed 44 characters. Thus, a maximum of 22 simple names can make up a data set name.

which sounds like the name in the VTOC DSCB. It also says, in "Data Set Storage} on pages 3-4:

Each data set stored on a volume has its name, location, organization, and other o control information stored in the data set label or volume table of contents (for direct-access volumes only). Thus, when the name of the data set and the volume on which it is stored are made known to the operating system, a complete description of the data set, including its location on the volume, can be retrieved. Then, the data itself can be retrieved, or new data added to the data set.

...

Keeping track of the volume on which a particular data set resides can be a burden and a source of error. To alleviate this problem, the system provides for automatic cataloging of data sets. The system can retrieve a cataloged data set if given only the name of the data set. If the name is qualified, each qualifier corresponds to one of the indexes in the catalog. For example, the system finds the data set DEPT58.SMITH.DATA3 by searching a master index to determine the location of the index name DEPT58, by searching that index to find the location of the index SMITH, and by searching that index for DATA3 to find the identification of the volume containing the data set.

By use of the catalog, collections of data sets related by a common external name and the time sequence in which they were cataloged (their generation) can be identified; they are called generation data groups. For example, a data set name LAB.PAYROLL(0) refers to the most recent data set of the group; LAB.PAYROLL(-1) refers to the second most recent data set, etc. The same data set names can be used repeatedly with no requirement to keep track of the volume serial numbers used.

so what is it that the catalog does? It sounds as if it keeps track of the volumes on which files resides, and maybe is involved with generation data groups.

It sounds as if the data set name is hierarchical if used to look the data set up in the catalog, but is just a name in a flat namespace in the VTOC; how does that affect the syntax for the names of cataloged data sets vs. non-cataloged data sets? Guy Harris (talk) 06:15, 14 May 2025 (UTC)[reply]

The catalog is hierarchical, based on the 8 character qualifiers. The description above says automatic cataloging, which didn't used to be true. (I knew this back to OS/360 days.) The VTOC stores the 44 character name. System files are always cataloged, but, at least in OS/360 and OS/VS days, user files didn't have to be. If not, you have to specify the volume name: (VOL=SER=...) on the JCL every time. Also, VSAM data sets are required to be cataloged. Gah4 (talk) 23:18, 4 December 2025 (UTC)[reply]

Weak start

WRT "A file name is used to uniquely identify a computer file in a file system"

Uniquely? Yes and no. Uniquely across the file system? no. And with hard links, a file can have multiple names so it's not unique that way either. On this point, it's unique within a directory (if we ignore the hard link thing). But, I don't think that's a good way to start the article.

Thing is, we're not saying what it is; we're saying what it's used for which is just lame. What is it? That's what we want to know; first. It's a human readable identifier for a file. Stevebroshar (talk) 16:58, 27 September 2025 (UTC)[reply]

Different file systems impose different restrictions on filename lengths

WRT the second sentence of the article "Different file systems impose different restrictions on filename lengths"

It's not wrong, but is awkward as the second sentence for the topic. It's not _that_ important. Stevebroshar (talk) 16:59, 27 September 2025 (UTC)[reply]

It's two words

Spoiler alert: it's two words.

Yes, programmers use 'filename' alot. But that's jargon; techno babble. We should note that, but we should write this for the normal human population; not programmers. Stevebroshar (talk) 17:01, 27 September 2025 (UTC)[reply]

APFS disallows colons in file names?

The table entry for APFS claims that it disallows colons in file names - and, given that it's a Unix file system, and Unix/Unix-like systems such as macOS allow colons in file names, presumably would then store a colon in a file name as a slash, and map between colons and slashes, just as HFS+ does.

This seems unlikely. HFS+ was originally a file system for the classic Mac OS, in which colon was used as a separator in pathnames and slashes were allowed in file names; when it turned into a Unix file system for Mac OS X, it converted colons to slashes in file names stored in the file system, converted colons in file names in lookup-by-name operations into slashes when looking for the file in the catalog, and, in "read directory" operations, mapped the slashes back to colons in the returned file names. This allowed HFS+ volumes written by the classic Mac OS to be read by Mac OS X - and allowed volumes written by Mac OS X to be read by the classic Mac OS.

(Some OS layers above the Unix layer in macOS support slashes in file names, for user-experience compatibility between the classic Mac OS and Mac OS X/macOS, but that's file system independent - it was done on UFS volumes, and is done on VFAT volumes, HFS+ volumes, APFS volumes, AFP-mounted/NFS-mounted/SMB-mounted volumes from other hosts, ISO 9660/UDF volumes, etc. That mapping is completely independent of the mapping done inside the HFS+ implementation.)

APFS was never a classic Mac OS file system, and would thus have no requirement to disallow colons in file names and map them to slashes, rather than, like other file systems designed for Unixes, just disallowing slashes and allowing colons.

In addition, unless I've missed something, the the linux-apfs-rw APFS implementation appears to do no such mapping; if Apple's implementation does such a mapping, the linux-apfs-rw implementation couldn't read volumes written by macOS and vice versa.

So, if it's true that the mapping is done, there needs to be a reliable source to support that claim. Guy Harris (talk) 18:08, 28 September 2025 (UTC)[reply]

I don't understand much of what you say. Too much detail. This article is about file name in general which does not seem like a good place to include so much detail about how naming works in apple-land and the history of it all. That belongs in APFS; not here. ... The note for that cell says: "In Finder, a name containing / can be created, but it is stored as a :. A file created from the command line with a : is shown with / instead of : so that it is impossible to create a file that the Finder shows as having a : in its name." ... That's a lot of words and IMO is less than clear. I read "impossible to create a file that the Finder shows as having a : in its name" and summarized it as "forbids :". Even if a colon is stored for slash, I stand by the "forbids :" as accurate in the sense that via the primary GUI for the file system, it seems that : is not allowed. ... I'll dive into why I think the note is less than clear. The note implies that a user can enter a file name with slashes in Finder, but each slash is stored as a colon. Makes sense since in a Unix-like FS slash is the path separator whereas it was colon in older Mac FS. So, APFS prevents storing a slash (a path sep) by mapping each input slash to a colon (was path sep in older FS, but not special in Unix land). But, this begs the question: what is colon shown as in Finder? It would be nice if a colon that was stored for a slash (by Finder) shows as a colon (in Finder), but what if I name a file with a colon? I don't want that to show as a slash, right? If a slash is stored as colon (without other markup), then there's no way to distinguish entered-colon vs entered-slash so I assume entered-colon shows as slash! I assume that a stored colon is shown as slash. If you create a file with a colon (via command line, Finder or whatever), it will show in Finder as a slash (which IMO is wonky as heck! But, my opinion on good UX has nothing to do with how HPFS works.) ... Maybe Finder disallows colon entry. IDK, but we quickly get into quirky behavior that IMO does not belong in this article. ... So, what should we say here? Maybe: "Forbids / but since since Finder shows a : as a /, it seems that : is forbidden instead". Stevebroshar (talk) 12:29, 29 September 2025 (UTC)[reply]

Too much detail. Sometime detail is necessary to make clarify misconceptions.

This article is about file name in general which does not seem like a good place to include so much detail about how naming works in apple-land and the history of it all. This is a talk page, not a Wikipedia article; the details are there to explain what's going on in case the whole bit about APFS disallowing colons in file names is the result of somebody misunderstanding what's going on with file names in macOS and drawing an incorrect conclusion without any data.

The note for that cell says: "In Finder, a name containing / can be created, but it is stored as a :. A file created from the command line with a : is shown with / instead of : so that it is impossible to create a file that the Finder shows as having a : in its name." ... That's a lot of words ...and, quite frankly, doesn't belong here; it's on my to-do list to remove.

None of that is relevant to any particular file system, as it's stuff that's done at a layer above 1) any individual file system implementation, 2) the VFS layer in XNU, and 3) the Unix file system APIs, and is thus completely file-system-independent. It happens for HFS+ volumes, it happens for APFS volumes, it happened for UFS volumes when macOS supported them (back when it was still called "Mac OS X"), it happens for VFAT volumes, it happens for NFS and SMB mounts, it happened for AFS mounts when macOS supported them, it happens for CD-ROM and DVD-ROM mounts, etc., etc.. It has nothing whatsoever to do with whether / or : is supported, on disk, in file names in some particular file system.

I read "impossible to create a file that the Finder shows as having a : in its name" and summarized it as "forbids :". The "it" that "forbids :" is the Finder and possibly some APIs that, as noted, run well above the underlying macOS API that creates files on, namely open(). It's not any particular file system' that forbids it.

The note implies that a user can enter a file name with slashes in Finder, but each slash is stored as a colon. The Finder shows file names with colons in them by replacing the colons with slashes and if, for example, you rename a file to a name that contains slashes, the slashes get converted to colons before being passed to the rename() call to do the rename. Again, this is done well before the implementation of whatever file system the file resides on sees the name; it's not done by the file system. (And it's done to make transition from the classic Mac OS to Mac OS X easier for Mac users. They might, for example, have created files with slashes in their names, and not expect them to pop up with colons in the name once they boot Mac OS X.)

HFS+ happens to do the opposite mapping, converting the colons to slashes before entering the file name in the catalog, and converting slashes to colons before returning the file names in the results of a getdirentries() call, for separate backward-compatibility reasons, as I described. APFS has no such backward-compatibility-with-classic-Mac-OS requirements - it's a file system designed to be used in a UNIX(R) system (and Apple's other Unix-like-but-not-certified-as-UNIX(R) OSes).

So, APFS prevents storing a slash (a path sep) by mapping each input slash to a colon (was path sep in older FS, but not special in Unix land). No, the XNU kernel namei() prevents storing a slash by treating slashes as path separators so that no file system implementation sees a path component containing a slash. (If there's any in-kernel code that bypasses namei(), e.g. by directly calling the VFS_ routines, it should also do so; if, for example, the NFS server does so, it should reject NFS requests that try to create files with names such as "I/O subsystem.txt". And, if I remember correctly what I did over 20 years ago, I think I had to do that in the NetApp NFS server code.)

But, this begs the question: what is colon shown as in Finder? A slash. (That is not relevant to what Filename discusses.)

So, what should we say here? Maybe: "Forbids / but since since Finder shows a : as a /, it seems that : is forbidden instead". Yes...

...as long as we say it about every single file system in the table that is supported on macOS, because that behavior is not specific to HFS+ and APFS.

But that would be discussing stuff (the behavior of code in macOS that runs above the Unix API layer in macOS, and does so on all file system types) that's not relevant to filenames in file systems, so it doesn't belong on this page.

So we say nothing about the Finder. And, unless somebody comes up with a reliable source to support the notion that APFS does any colon <-> / mapping, we change the APFS entry in the table to say it forbids /, just as every other Unix file system does (either because the file system implementation does, or because the code into which the file system implementation plugs does). Guy Harris (talk) 17:02, 29 September 2025 (UTC)[reply]

Yes. Too much info. And you are now throwing gas on the fire to put it out. Relax. The topic at hand is whether APFS allows or forbids colon. You have written 19 paragraphs about this; about 18 too many :) ... I hate to dive into the weeds, but WRT {I read "impossible to create a file that the Finder shows as having a : in its name" and summarized it as "forbids :". The "it" that "forbids :" is the Finder} ==> I think you are referring to "summarized it" where it refers to the statement in the text; not Finder. ... You seem overly focused on what aspects of the OS do what. It's a good line of thinking, yes, but chill out dude. Let's get to a resolution, not spiral out about minutia. ... WRT {So, what should we say here? Maybe: "Forbids / but since since Finder shows a : as a /, it seems that : is forbidden instead". Yes... } Yay. we have consensus. WRT {...as long as we say it about every single file system in the table that is supported on macOS, because that behavior is not specific to HFS+ and APFS.} Relax. We can fix one thing without having to fix everything. And also, let's fix them all :) I'm down for that. You make it seem like I am opposed to changing other entries. I'm not :) ... WRT "...that would be discussing stuff ... that's not relevant to filenames in file systems ... So we say nothing about the Finder." You are a black and white thinker. I agree that an article should stay on topic, yes, but I think that a little tangential info can be OK. I don't think an article about file name should include minute detail about every apple OS and its history. But if Finder shows colon as slash, that seems relevant and good. ... You beat the reliable source drum. Let's talk about that. This table is severely lacking in that regard, right? All the info _should_ be cited, yes. But, here's the reality: we don't have sources! Yet the info is there. If adding a source is not an option, then what do we do? Delete it? Change it to what we know? Bury our heads by saying: we need a source? IMO we don't need a source to justify changing it. It's fine to change it to what we know is correct and maybe even add a citation-needed template to put a bow on it. But leaving inaccurate info bc we don't have a source is a bad path IMO. Inaction is a choice; sometimes a bad choice. ... I can tell that you care about WP and put alot of good work into it. I hope some day to meet you. Your tone sometimes comes across as adversarial. Maybe mine does too. But, I think you are acting with the best of intentions. Keep up the good work. Stevebroshar (talk) 10:42, 30 September 2025 (UTC)[reply]

(When I'm discussing a topic, I attempt to preemptively dispel misconceptions before people make false arguments based on those misconceptions; the sooner those misconceptions are corrected, the better. Perhaps this results in more words than some people might want to read.)

You seem overly focused on what aspects of the OS do what. Restrictions on file names are imposed at several layers:

1. The layout of the file system imposes some limitations, e.g. the original Unix file systems had 16-byte directory entries, with 2 bytes of inode number and 14 bytes of file name.
2. The specification of the file system imposes some limitations, e.g. it may specify the character encoding or encodings that are to be used in the file name data fields (the layout only says that a file is 14 bytes long or 255 bytes long or 4 36-bit words long or...).
3. The operating system's file access APIs impose some limitations, e.g. Unix and Unix-like systems use null-terminated strings for path names, meaning that the NUL character can't be used in a file name, and they use slash as the path name separator, meaning that the slash character can't be used in a file name.
4. Code running atop those APIs may impose additional limitations, e.g., in macOS, for (now-perhaps-historical) code and user compatibility-with-classic-Mac-OS reasons, some APIs, and the Finder, do the already-mentioned slash/colon exchange.

Over and above that, particular file system implementations may do other things, such as the slash/colon exchange done in the HFS+ implementation - again, for now-historical compatibility reasons. (That exchange is completely separate from the one done in the Finder, even if both are done for compatibility-with-classic-Mac-OS reasons; the Finder/Carbon/etc. ones are done on all file system types.)

The table should make it clear which limitations are limitations of particular file systems and which are OS limitations, and, given the HFS+-on-Unix behavior, should make it clear that "what's on the storage medium" may be different from "what's in file names that code and users see". (Another example is Files-11 ODS-1; the file names are stored in RADIX-50, but, at least on VMS, the file names provided to and returned by APIs are in ASCII.)

That's why the OS layer at which stuff is done matters; focusing on that is important, so we don't spread misconceptions.

But, here's the reality: we don't have sources! Yet the info is there. If "there" is some place to which we have access, use that place as the source. If it's in some place to which we don't have access, we don't know what the info is, so we are not in a position to make assertions about what is the case.

In particular, somebody asserted that APFS does the same colon/slash mapping that HFS+ does. I have seen precisely zero evidence to support that assertion, and the compatibility reasons why HFS+ does that mapping do not apply to the never-used-on-Classic-Mac-OS APFS, so it is not at all clear why Apple would throw extra stuff into the code path to do that.

If adding a source is not an option, then what do we do? Delete it? Yes, delete it, where "it" is the "APFS doesn't allow colons in file names" claim. That claim may just be the result of somebody blindly assuming that APFS must be doing the same stuff HFS+ does, without an understanding of why HFS+ does that and why those reasons do not apply to APFS.

In fact, I'd say that filename limitations imposed by various layers of the OS should be discussed separately from filename limitations imposed by particular file systems. In an OS using, for example, > as a pathname separator (yes, there were operating systems that did), one could conceivably use a Unix file system to store files with slashes in their names, and disallow > in file names. That would prevent unplugging an external drive from that OS, plugging it into a Unix/Unix-like system, and accessing all files on that drive from the Unix/Unix-like system, or moving a drive from a Unix/Unix-like system to that OS and accessing all files on that drive from that OS. To fix that, a >/slash exchange could be done in the implementation of that file system on the other OS, just as was done when the Unix-like Mac OS X used a classic Mac OS file system, HFS+, as one of its file systems, and needed to make it possible for both the classic Mac OS and Mac OS X to access all files on HFS+ volumes. Guy Harris (talk) 18:03, 30 September 2025 (UTC)[reply]

Comparison of filename limitations doesn't belong here

The info in the Comparison of filename limitations table is not about limitations of file name. It's about the behavior of various file systems that affects/limits/restricts file naming. The table does not belong in this article but does seem to fit in the context of Comparison of file systems. So, let's move it there. Stevebroshar (talk) 12:45, 29 September 2025 (UTC)[reply]

This article's title doesn't contain the word "Comparison", so offloading comparisons between file systems to Comparison of file systems makes sense. If this article discusses filename lengths, it should just note that, even within a single operating system, filename lengths may differ on different file system types.

(The same can apply for problematic characters, e.g. Files-11 ODS-1 only supports RADIX-50, even on VMS, but ODS-2 supports some characters not supported in RADIX-50 - and then there's ODS-5, but that's another can of worms, for which RMS may be doing its own stuff, atop the lowest-level file system APIs. Backwards compatibility is a real can of worms.) Guy Harris (talk) 20:53, 30 September 2025 (UTC)[reply]

Must be unique?

WRT "Within a single directory, filenames must be unique", I agree that that is how every file system I've used works, but... the 'must' is overselling. A file system could allow duplicate names. There's no inherent rule or reason for disallowing duplicate names. Yes, it makes a ton of sense to disallow duplicate names and that's why all file systems do that. But, I can imagine a usable file system that doesn't. Oh, wait, google docs allows multiple with same name! Is that a file system? It's not like what we normally think of as a file system, but it looks and feels like a file system. (If it smells and tastes like chicken, then it's chicken, right? Or maybe it's snake since most things taste like chicken. But, I diverge from my point.) My point is that normally/usually a file system disallows duplicate names, but "must be unique" is not accurate. Stevebroshar (talk) 13:05, 29 September 2025 (UTC)[reply]

HFS+ content restrictions

WRT "Forbids : on disk and the classic Mac OS; maps between : in file names and / on disk in macOS" (in table entry for HFS+)

What is the intent here? Is the semicolon supposed to be there? Does the FS forbid : on disk and the classic Mac OS? Or does the Classic Mac OS map between : and /? What does "on disk" imply? What does Classic Mac OS have to do with APFS? And use of 'disk' is antiquated today when we often use SSD now. But, talking about storage is spiraling off topic. This article is about file names, not storage.

What does "maps between : in file names and / on disk in macOS" supposed to mean? This seems to make a distinction between "file names" and "on disk" but these two things are not compatible things.

Is the intent that : is forbidden by the FS? And that something (finder?) shows : as slash (opposite of APFS)?

How about this: "Forbids : (note: Since Finder shows a / as a :, it seems that / is forbidden instead of : ... which is the opposite behavior of newer Apple systems)" Stevebroshar (talk) 11:15, 30 September 2025 (UTC)[reply]

Does the FS forbid : on disk A file name with a colon in it would be inaccessible from the classic Mac OS. If you're only using HFS+ on the classic Mac OS, the OS APIs would, as far as I know, make it impossible to create a file with a colon in its name; however, if you're using HFS+ on the classic Mac OS and on Mac OS X/OS X/macOS, the latter OSes have no problem with colons in file names. So, in the HFS+ implementation on Mac OS X, they did the colon/slash swap; see the USENIX paper The Challenges of Integrating the Unix and Mac OS Environments, which also mentions the separate Carbon/Finder colon/slash swap.

I.e., the classic Mac OS forbids file names with colons in them, just as Unix/Unix-like operating systems forbid file names with slashes in them, at least from the OS API layer. (Some Un*x NFS servers failed to prevent clients from creating files with slashes in their names, which would allow an NFS client that's not a file system module in a Unix system to create such a file, which could not be accessed or removed from the Unix layer. Those were bugs in the NFS servers in question, and I think have mostly been fixed by now.)

I don't know whether the HFS+ code in the classic Mac OS included its own code to disallow colons in file names; I'm not even sure how the classic Mac OS handled different file system types internally, so I don't know how meaningful a distinction between the classic Mac OS file system API code and the code for particular file system formats can be drawn.

Or does the Classic Mac OS map between : and /? No. The HFS+ implementation in Mac OS X/OS X/macOS does that, as it's the one that needs to be Unix-compatible and to handle HFS+ volumes from the classic Mac OS - it's the newer OS.

What does "on disk" imply? It implies "on the storage medium". For example, the in-memory string "Rambo: First Blood", passed to the open() routine in macOS, would be passed, as is, through the VFS layer down to the HFS+ code, when a "lookup" operation is done. The HFS+ code would search for a file whose name, on the storage medium, is "Rambo/ First Blood". If it found it, it would return a node for the file. If it were a "create" operation, then, if the name weren't found, the HFS+ code would create a file whose name, on the storage medium, is "Rambo/ First Blood".

What does Classic Mac OS have to do with APFS? Nothing, which is why I'm extremely skeptical that it bothers to do the slash/colon swap, as it has no reason to do it.

And use of 'disk' is antiquated today when we often use SSD now. Yes, but I didn't bother changing it at the time I was editing.

But, talking about storage is spiraling off topic. This article is about file names, not storage. Then we should completely remove from the table the stuff about forbidding colons or slashes, as those - unlike, for example, character encoding restrictions or file name length restrictions - aren't restrictions inherently imposed by the file system, they're restrictions imposed by the pathname conventions of the operating systems in which those file systems are being used.

What does "maps between : in file names and / on disk in macOS" supposed to mean? It means that the macOS HFS+ implementation does the mapping described in the USENIX paper.

This seems to make a distinction between "file names" and "on disk" but these two things are not compatible things. File names can reside on a file system storage medium; they can also reside in a string in memory being passed to a file system API. A file system implementation is not required to store on the medium the exact string of words/bytes/whatever passed to it from a layer above it, although, if it's going to do sleight-of-hand with file names passed to it, it has to undo that sleight-of-hand when passing file names back up (the HFS+ implementation in macOS does both, which is why readdir() and other lower-level directory-reading APIs show file names containing colons, regardless of whether they're reading from HFS+ or some other file system - and why programs using those APIs, including ls and the Carbon code - see colons when they read directories. Carbon may map them to slashes for the benefit of Carbonized applications from the classic Mac OS, and the later Cocoaized Finder may get file names with colons from the Foundation Kit APIs it uses and convert the colons to slashes itself.

Is the intent that : is forbidden by the FS? The intent is that

• filenames with colons are not allowed by the classic Mac OS (filenames with slashes are allowed);
• a given HFS+ file system might be used both by the classic Mac OS and by macOS, and all files should be accessible to both operating systems;
• macOS, a UN*X, must allow filenames with colons (but doesn't allow filenames with slashes);
• in order to square this circle, the HFS+ implementation on macOS does the colon/slash swap;

(APFS does not have the compatibility constraints that HFS+ has, and thus APFS almost certainly does not do that swap).

And that something (finder?) shows : as slash The now-defunct (as of macOS Catalina) Carbon API did that, so the old Carbon-based Finder did that - the newer Cocoa-based Finder does so itself (unless there's something I missed when looking at the Foundation Kit documentation that allows Cocoa-based apps to get classic Mac OS-style file names; I remember from back when I was in the remote file system group in Core OS at Apple that some APIs above the Unix layer could requires path names in more than one format - including URLs - but I forget which ones they are). In addition, file dialog boxes in applications, for example, also do that mapping; that's outside the Finder application.

How about this: "Forbids : (note: Since Finder shows a / as a :, it seems that / is forbidden instead of : ... which is the opposite behavior of newer Apple systems)" How about removing all mention of the Finder from entries in the table, and, instead:

• let Filename § Reserved characters and words, rather than the table in Filename § Comparison of filename limitations, handle the OS-specific file name limitations;
• mention the Finder stuff, which is file-system-independent, in that section;
• note, somewhere, that if a file system type is used on OSes with different file name limitations, implementations of that file system type might perform various mappings to work around the problems this causes, including the mappings done by the HFS+ file system;
• perhaps rename Filename § Comparison of filename limitations to Filename § Comparison of file-system-specific filename limitations or something such as that. Guy Harris (talk) 20:37, 30 September 2025 (UTC)[reply]

Or just throw Filename § Comparison of filename limitations out, as per Talk:Filename § Comparison of filename limitations doesn't belong here. Guy Harris (talk) 21:00, 30 September 2025 (UTC)[reply]

255 UTF-8 characters?

For APFS, allowed chars is UTF-8 and the length restriction is 255 characters, but UTF-8 is a multibyte char set. Is the restriction really chars? or is it bytes? I assume the latter. Not that I know one way or the other, but dubious is apt here. I'll bet it's 255 bytes. Stevebroshar (talk) 11:32, 30 September 2025 (UTC)[reply]

For most if not all Unix file systems, the restriction, at least within the file system, is bytes. This is not an APFS-specific issue, nor is it a UTF-8-specific issue; it would apply to any multibyte character encoding, e.g. it also applies to Extended Unix Code encodings. Guy Harris (talk) 18:08, 30 September 2025 (UTC)[reply]

For UTF-16 that Problem is the same. In the OnDisk-Structures of NTFS is Space for up to 255 16-Bit-Words (up to 510 Bytes) what can typical hold up to 255 Characters but if you use Characters with an Unicode-Code-Point above U+0FFFF than it does use two 16-Bit-Words for each of that Characters and that does mean the maximum possible Number of Characters is reduced. In my opinion that Fact is in the whole Table not described correctly. Erik 2003:ED:F7FF:1D8A:3981:162:7416:8D53 (talk) 21:09, 25 October 2025 (UTC)[reply]

Errors in the Table with the filename limitations

in the table mentioned are some Errors, IMHO, :

for "VFAT" and "exFAT" is describted that the Code 255 is forbidden but in UCS-2 and UTF-16 (both are 16Bit-Encodings) is the Code 255 the Character ÿ / ÿ and that is a valid Character, for real 8Bit-Encodings (like the short Names in FAT*) the Byte 0xFF is forbidden but in Unicode the Code 255 is allowed. In my Opinion that is an Error in both rows of that Table.

for "NTFS (on Windows)" is written "Forbids codes 1–31", why not Code 0 ?   As far as i know is the Code 0 forbidden in all Access-Mechanisms for NTFS. In my Opinion that is an Error in the Table.

Should i fix it or are there objections? Erik 2003:ED:F7FF:1D8A:3981:162:7416:8D53 (talk) 20:58, 25 October 2025 (UTC)[reply]

WP:Be bold! – LuniZunie ツ_(talk) 20:59, 25 October 2025 (UTC)[reply]

What is about the Unicode-Byte-Order-Mark as Part of a Filename?

as the Topic-Name says, what is about the Unicode-Byte-Order-Mark in Filenames? It is a valid Code-Point for all Unicode-Variants (UTF-8 & UTF-16 & UTF-32) with the Codepoint U+FEFF (is in UTF-8 meaningless but can be encoded as EF BB BF there, that three Bytes are valid UTF-8 but meaningless). Does the official Specifications of the Filesystems mention it or descripe a recommended handling for that Codepoint? What will do a Operating-System (or its File-System-Driver) if that Codepoint is present in a Filename on Disk? As the first Character in a Name or as any later Character in a Name?
Has anyone Informations about that Issue?
Erik ~2025-38488-59 (talk) 17:47, 4 December 2025 (UTC)[reply]

It depends on the operating system and the particular file systme type.

In macOS, on an APFS (case-insensitive, but that probably doesn't make any difference) file system, it just creates a file the first three octets of whose name are 0xEF 0xBB 0xBF; file names are stored in UTF-8 on APFS.

I haven't tried it on an HFS+ file system, which stores file names in UTF-16, probably big-endian although the HFS+ specification doesn't explicitly say so. My guess is that, on macOS, it stores it as a UTF-16BE BOM. I don't know what the classic Mac OS does.

I suspect most UN*Xes and most UN*X file systems would just store the BOM as 0xEF 0xBB 0xBF.

I don't know what Windows does, whether on VFAT or NTFS or ReFS.

Does the official Specifications of the Filesystems mention it or descripe a recommended handling for that Codepoint? The HFS+ specification does not mention it. Neither does the APFS specification. I suspect few if any other UN*X file system specifications do. I don't know whether there are any public VFAT, NTFS, or ReFS specifications.

As the first Character in a Name or as any later Character in a Name? I suspect that few, if any, UN*X file systems care whether it's at the beginning of the file name or not. (Given that the core UN*X file system APIs take octet strings, not UTF-16 code unit strings, as arguments, the BOM provides no useful information.) Guy Harris (talk) 07:29, 5 December 2025 (UTC)[reply]