Talk:List of filename extensions

message: Why name it Windows * ?  The file name extensions are for all OS, we hope. 
Good to have a complete set arranged alphabetically.  In fact, I would like 
to see additions to this set, with links to the associations and companies 
that do most with the extensions. 
--Steve Irick.  —Preceding unsigned comment added by 75.48.78.4 (talk) 00:53, 28 February 2009 (UTC)
thread_title:  Talk:List of file formats (alphabetical);  Keep this!  

message: .mpa also seems to be an extension used by the Palm Desktop application.  Is there any concensus reason that use should not also be listed here? -Onceler (talk) 22:16, 3 July 2009 (UTC)
thread_title:  .mpa 

message: Talk:Windows file types for details. —Nethac DIU ([[User talk:Nethac DIU|¿?), wuz heer about 01:03, 19 March 2010 (UTC)
thread_title: Proposal of massive merge

message: This is a useful page - I have a bookmark directly to it - so why on Earth is it
marked for deletion?
Paul Taylor (talk) 19:15, 7 February 2009 (UTC)
thread_title: Merge/Deletion discussion

message: Any discussion of the file suffix, or extension, should include reference to Digital Eqpts, Rad50 notation, which is why the great body of extensions are limited to three characters.    Rad50, or more properly RAD50 was an encoding scheme to put 3 characters into 16 bits.  26 letters, 10 digits, and sufficient other characters, excluding i believe the period (.), slash (/) and bs (\\), since they are part of the filename delimiters, and hence could NOT be part of the suffix are the 50 potential suffix characters (if not part of the name).   So 50^3rd/ 2 (somehow)   = 62500, which fits in a 16 bit binary.   
Windows is merely a "johnny-come-lately" adopter of this scheme as well.
Applemcg (talk) 01:31, 27 August 2009 (UTC)
replies: text: I agree that RADIX-508 should be mentioned in the filename extension article. The popularity of that encoding on early computers is almost certainly the reason that extensions were limited to no more than three characters from a small character set "for compatibility" for many decades. And so I agree that RADIX-50 should be mentioned in the file extension article. --DavidCary (talk) 21:38, 20 June 2015 (UTC)
thread_title: Rad50

message: This discussion has been lingering for more than a year, therefore I have just stripped the "please merge with the windows article" warning.
BTW, while every article should be properly sourced, I found the warning against the lack of source slightly inappropriate because of the copyvio justification: copyright does not cover lists of facts nor small excerpts a few words long. Since the article has some sources anyway, I removed the "please cite properly" alertbox as well. Regards, Comte0 (talk) 13:22, 11 April 2010 (UTC)
replies: text: Fair enough BUT the deletion discussion linked above specifically states that the merge should take place, this is effectively a condition of the article being kept and so the merge warning should remain. Polyamorph (talk) 14:56, 12 April 2010 (UTC)
replies: text:  Merging with list of file formats, perhaps; with Windows file types, certainly not... Comte0 (talk) 12:23, 18 April 2010 (UTC)
replies: text: Yes, ok my mistake. Polyamorph (talk) 12:29, 18 April 2010 (UTC)
thread_title:  Removal of the warnings 

message: Most file types are shown upper case. I think because it started with Windows and looks neat.
However, on platforms with case senstitive file systems like unix it makes a difference, whether an extension is uppercase or lowercase. In fact, most extensions are lowercase on such systems.
We could ignore this, but e.g compiling a .c file would invoke the C compiler while .C would invoke the C++ compiler. I think the names should be converted to lower case where it is known to be safe. Marcel Müller (talk) 08:16, 6 June 2010 (UTC)
replies: text: Under unix, you do not double click on a file and expect the proper program to be magically invoked, you invoke the program passing the file as an argument. For instance, to compile a C file, you invoke the compiler like this: cc file.c, or cc file.C: the file can be named any way you want and the extension is not important. The split program indeed produces lower case extension, but I do not feel it's that important either. Regards, Comte0 (talk) 12:48, 6 June 2010 (UTC)

text: Hum. Looking it up further, the difference between .c and .C is a special case, at least for gcc, and probably for other c compilers, it should be noted in the article. Comte0 (talk) 13:06, 6 June 2010 (UTC)

text: To respond belatedly, there are multiple reasons that they should definitely be (and remain) lower-case by default. Mainly, per MOS:CAPS: do not capitalize anything unless it is almost always capitalized in reliable sources.  Here, the OP's reason is also additionally compelling. There are proportionally very few instances where the case makes a difference, but when it does, we have occasional instances of mandatorily capitalized extensions in *n*x, in a vast sea of normally lower-cased extensions, so we clearly need to use LC for most of them, and UC only for the rare ones that require it.  — SMcCandlish ☏ ¢ 😼  07:24, 30 August 2020 (UTC)
thread_title:  Case sensitivity 

message: Split - Article is over 100 kB and should be split.  Thoughts?  Suggestions?--Jax 0677 (talk) 02:28, 16 December 2012 (UTC)
replies: text: I think that this is one that should have had a letter per page, we can safely assume that the article will expand in the future. Best to do it properly now than have to keep on tinkering. Op47 (talk) 20:50, 8 February 2013 (UTC)
thread_title:  Size split? 

message: Please see post on possible duplication at Talk:List_of_file_formats#Duplication Rui Gabriel Correia (talk) 00:19, 10 January 2014 (UTC)
thread_title:  Duplication 

message: There are at least two problems related to Unix file types.
1. Unix file names are case sensitive. BLAH.TXT and blah.txt are two separate files, for example. This especially applies to the fact that a .Z file and a .z file are not the same thing, even in terms of the formats and the commands to make them.
2. Unix commands are also case sensitive. As of the creation of this section, the file listing for the above file types, which mistakenly lists .z and .Z as interchangeable, mentions non-existent PACK and COMPRESS commands, using the format that DOS commands use. The program for making .Z files is always referred to as compress, using the all-lowercase format of every other Unix command.
I will probably eventually correct at least some of these pages (especially since ALL CAPS has become equivalent to yelling after the Internet became widespread). --Evice (talk) 14:13, 26 October 2014 (UTC)
thread_title:  Unix-related problems 

message: The lists appear to be bogus, a random unsourced collection of wannabe file-extensions. How about limiting the lists to existing pages including redirects? E.g., the two entries for JOB don't match my (Windows) idea of an ancient at command .job. –Be..anyone (talk) 22:53, 11 April 2016 (UTC)
thread_title:  Bogus lists 

message: I have started the cleanup work. .3ds is already an interesting problem; seems like this file format has been reverse engineered a bit, but I'm not comfortable using those documents as references. Are official documents available? Searching around autodesk.com didn't get me anything. -- Mikeblas (talk) 18:28, 12 September 2020 (UTC)
replies: text: As above, I guess I'm actually leaning toward the reverse-engineering work being an independent source that goes to notability. Is there precedent for this pattern? -- Mikeblas (talk) 03:03, 13 September 2020 (UTC)
replies: text: It would probably qualify as independent sourcing, as long as there's non-trivial coverage in some source other than that of the reverse-engineer's self-publication.  E.g., the .ESP/.ESM format used by Gamebryo Engine games (mostly from Bethesda/Zenimax) was only partially documented, but has long been figured out in great detail by the coding teams behind tools like xEdit, and the format facts have since been verified and repeated by others like UESP (which has an editorial board who carefully review content; it is not an open public wiki), by the Wrye Bash project, by the STEP project, etc., etc.  But if I personally published a claim to have reverse-engineered some new format, that's just self-published (WP:SPS) material if you only find it on my personal website or Discord feed.  — SMcCandlish ☏ ¢ 😼  15:49, 15 September 2020 (UTC)
thread_title: Cleanup

message: More than half-way done, I think. I've left some unreferenced entries that seem like they might be viable, but I haven't researched yet. Lots of references added, and masses deleted. Any feedback or comments, concerns? -- Mikeblas (talk) 15:47, 25 September 2020 (UTC)
replies: text: OK, I'm putting a button on this effort and calling it done. I've deleted lots of unreferenced, non-notable entries and added dozens of references. I've left behind things that are apparently notable, but they still really do need real references. I'll update the headers for each of the pages presently. -- Mikeblas (talk) 14:19, 5 November 2020 (UTC)
thread_title: Cleanup Progress

message: Currently, the table of contents seems to have been copy-pasted across each of the different sup-pages, often with notable differences.
Would it be a good idea to make a template just for this list? I'm not super familiar with the standards for making new templates, but also the current state is a bit of a mess. Binarycat64 (talk) 00:07, 1 February 2022 (UTC)
replies: text: I think that would be helpful! -- Mikeblas (talk) 14:56, 8 September 2022 (UTC)

text: I've made the ToC itself a template, but not the "see also" links. -- Mikeblas (talk) 18:32, 8 September 2022 (UTC)
thread_title:  Make TOC into a template?