This article is rated B-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||
|
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.83.78.62.69 (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".
Pediaguy (talk) 20:01, 20 June 2009 (UTC)
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)
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)
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)
"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)
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? 130.156.141.3 (talk) 20:49, 6 November 2012 (UTC)
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: \/:*?"<>|
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)
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)
I find the explanation of filename very confusing. Argument: I think a filename should be unambiguous.
I think the explanation of "filename" could be very compact and clear:
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))
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):
filename="file.txt"
filepath="C:\work\temp\file.txt"
foldername="temp"
folderpath="C:\work\temp"
Pediaguy (talk) 20:13, 20 June 2009 (UTC)
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)
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)
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)
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)
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)
$ 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)
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)
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)
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)
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)
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)
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)
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:
"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)
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)
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)
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:
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).
Cheers.—InternetArchiveBot (Report bug) 20:54, 20 July 2016 (UTC)
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.
Is it a joke? — Preceding unsigned comment added by 91.122.13.59 (talk) 18:20, 15 September 2019 (UTC)
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)
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)
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.argc
and argv
.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.""
as a literal "
, but don't ask me how common it was.
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)
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)
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)
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
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)