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)

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)

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)

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