- 1 "File name" vs "Filename"
- 2 Possible inaccuracies
- 3 Forward slash (/) on Windows
- 4 Other File Systems
- 5 Filename is not URL etc.
- 6 Confusion between 'filename' as a fully qualified (unique) name, a name for a file within a directory, or both
- 7 8.3 filenames
- 8 File system versus WIN32 API
- 9 Reserved characters and words mostly wrong
- 10 Merge Proposal
- 11 Meaning of basename
- 12 protocol and port are not part of file name
- 13 filename as an entity in a filesystem verses as used in a command or API
- 14 There IS a built-in tool to maintain hard links in Windows XP
- 15 length in bytes or characters?
- 16 Épône - Parking Gare01.jpg
- 17 Virus authors
- 18 Edit war over ==Usage==
"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)
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)
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.126.96.36.199 (talk) 13:22, 7 February 2008 (UTC)
"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".
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.
- 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?
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).-188.8.131.52 20:25, 11 April 2006 (UTC)
- 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)
"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 184.108.40.206 (talk) 15:11, 11 April 2008 (UTC)
- At Least Windows Exploere in Windows XP doesn't allow the creation of a file, if there is alreaqdy anothe rfile in the folder which is only differen in case, not even on NTFS partitions. So i.E. iif 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)
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)
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? 220.127.116.11 (talk) 20:49, 6 November 2012 (UTC)
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?)
- 18.104.22.168 16:42, 28 August 2006 (UTC) olivier Dulac
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)
- 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)
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)
- 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)
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. (22.214.171.124 (talk) 10:23, 24 April 2008 (UTC))
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)
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):
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. 126.96.36.199 (talk) 11:34, 13 June 2014 (UTC)
8.3 filenames can contain all ASCII-charakters (including the charakters 0x80-0xFF), except the charakters, which are reserved for special purposes. these charakters are not allowed. They are 0x00-0x1F, SPACE, DEL, " * / : < > ? \ | --MrBurns (talk) 00:03, 14 November 2008 (UTC)
- 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)
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 188.8.131.52 (talk) 18:58, 9 March 2009 (UTC)
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.
- 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. 184.108.40.206 (talk) 23:03, 6 November 2012 (UTC)
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)
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 ), so the basename of "foo/bar/baz.txt" is "baz.txt" (and not "baz"). This is also consistent with PHP (), Ruby , Python (, note also how "os.path.split() is defined), Visual Basic inside Microsoft Word 2003 () and so on.
Also note that the source cited in the article uses the expression "base file name" (and not "basename"). -- (talk) 18:40, 3 July 2010 (UTC)
protocol and port are not part of file name
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.
- For dot and dot dot I do not agree with you (see next link), althouth this might be system dependant.
- 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 220.127.116.11 (talk) 20:45, 9 October 2012 (UTC)
The article cites  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)
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)
- 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.≈≈≈≈18.104.22.168 (talk) 20:29, 9 October 2012 (UTC)
Épône - Parking Gare01.jpg
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 22.214.171.124 (talk) 21:33, 5 November 2012 (UTC)
"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 126.96.36.199 (talk) 13:15, 12 July 2013 (UTC)
- You raise two questions:
Edit war over ==Usage==
In this edit 188.8.131.52 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.
- 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 184.108.40.206 (talk) 12:02, 29 September 2013 (UTC)