Talk:Filename

"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.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)

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)

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)

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 62.17.140.34 (talk) 15:11, 11 April 2008 (UTC)

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)

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)

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)

This is still a problem in 2017. --NoToleranceForIntolerance (talk) 08:49, 20 June 2017 (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?)

82.196.52.11 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)

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)

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. (80.156.47.238 (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):
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

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)

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 70.88.209.29 (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.

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

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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.≈≈≈≈86.75.160.141 (talk) 20:29, 9 October 2012 (UTC)

É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)

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)

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)

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)

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)

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)

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: 18 January 2022).

• 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)

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)

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)

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)

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)

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)

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)

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)

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)

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)

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

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)

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)

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