Talk:Long filename

message: this article contains evidence contradicting this claim:
http://linuxboxadmin.com/articles/filefriction.php
what do y'all think? —The preceding unsigned comment was added by 69.249.82.16 (talk • contribs) 19:12, July 10, 2006  (UTC)
: The article is not available for public reading. 
37.47.37.21 (talk) 19:08, 11 June 2017 (UTC)
thread_title: microsoft as origin of long filename support

message: pages linking to "long filenames" (with a S) should be redirected here. right now it's only without a S. 70.111.218.254 13:41, 21 October 2006 (UTC)
replies: text: Done. — EagleOne\Talk 16:22, 21 October 2006 (UTC)
thread_title:  Add "long filenames" redirect 

message: "The reason they choose to do this is compatibility: volume labels are generally ignored by programs and operating systems apart in the root directory, notably they do not prevent the deletion of an otherwise empty directory."
I took out the second half of that sentence -- this was not a good place for it.  And I do not understand it.  If you do understand it, please put it back in an appropriate place, if there is one. 69.87.203.84 20:15, 21 January 2007 (UTC)
thread_title:  apart in the root directory 

message: When I move files from XP to Windows 98SE on a Creative Muvo MP3 USB flash drive, the short file and folder names that are all lowercase get changed to all UPPERCASE, and subtle problems ensue.  I assume that this is caused by the 8.3 representation, which is case-ambiguous.  Can someone explain exactly what is going on, and what are the best ways to avoid or fix the problem? 69.87.200.105 14:41, 22 January 2007 (UTC)
replies: text: See just above File_Allocation_Table#Third-party_extensions Platonides 21:22, 16 May 2007 (UTC)
thread_title:  UPPERCASE / lowercase problems 

message: I went through and cleaned up grammar and wording in there, and split off the paragraph on MacOS into its own section. I later changed my mind and reverted it. However, I'm not convinced that this is the place for that information. I'll ponder it for a while, but if no one comments I might remove it.
EvanED 04:40, 24 July 2007 (UTC)
replies: text: I have changed the title of the section from "Similar Implementation" to "Arbitrary selection of other file systems supporting more than 8+3 characters using different and mostly straightforward techniques". 1) It's more correct and 2) it might provoke support for the remove suggestion, or a restructuring. David A se (talk) 18:00, 3 March 2012 (UTC)
replies: text:  Yes, very funny, you've made you're point. But that wasn't very constructive. Perhaps this section should be more like "brief history of filename limitations". Quietbritishjim (talk) 01:20, 4 March 2012 (UTC)
thread_title:  Similar Implementation Section 

message: User TomViza made an edit that removed the following sentence: "The Windows implementation does not allow two files with the same name, even with different cases, such as “Example” and “EXAMple”. It will name the file in the way it is first referred to, and after that any form will match that one file. (This is called case preserving.)" The reasoning was that this is a limitation of FAT, not LFN, and didn't belong in this article.
I don't agree with this edit.
On one hand, it is a limitation of FAT, but at the same time, 8.3 filenames were also a limitation of FAT. LFNs removed (for all practical purposes) the limitation on length, and there is no reason the limitations of case-insensitivity couldn't have also been removed at the same time.
: It is *not* a limitation, it is a "difference from other file systems".
: Case sensitivity could not have been introduced at the same time, because that would have required existing software to be rewritten.  It would break even the most simple function like "does a file called this exist in this directory?".  Changing the maximum length of names however only broke badly written software (eg: using fixed length buffers, and not testing the length of what you write into them).
In other words, the limitation was present in FAT before LFNs, but MS made the design decision (that I agree with BTW) that file systems should be case-insensitive AGAIN when they implemented LFNs.
: The case (in)sensitivity of FAT was fixed before LFNs, and could not have been reliably changed with the introduction of LFNs, and so has no place in this article.
EvanED 00:04, 19 October 2007 (UTC)
replies: text: TomViza 12:14, 23 October 2007 (UTC)
thread_title:  Case Sensitivity 

message: Please explain how "chaining up to 20 directory entries of 13 2-byte unicode characters each" turns into statement that "long filename system allows a maximum length of 255 UTF-16 characters" when 20 by 13 is obviously 260? Microsoft states that "In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters.", see Naming Files, Paths, and Namespaces. Please add information that 255 equals MAX_PATH minus following: drive letter, colon, backslash, and a NUL symbol that terminates the name string (this is still 260 - 4 = 256): "A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string<NUL>" where "<NUL>" represents the invisible terminating null character for the current system codepage." This representation (\\?\filename<NUL>) gives you 255 characters for the filename. But! It allows for 32-bit addressing. Please explain this in this article; otherwise it is quite confusing.  — Preceding unsigned comment added by 78.111.95.34 (talk) 07:29, 23 June 2011 (UTC)
thread_title: MAX_PATH

message: : For example, file named "ABCDEFGHIJ" inside absolute folder location "C:\1234567890\1234567890" (Total of 21 characters excluding "C:\") can be renamed to a maximum of 234 characters.
I think the filename is completely irrelevant here! Could be a file name inside the absolute folder location [...] can be 234 characters long. The "ABCD..." is just confusing wrt the "21 characters")  — Preceding unsigned comment added by 46.223.21.105 (talk) 12:23, 14 March 2013 (UTC)
thread_title:  Example in Limitations 

message: Hello fellow Wikipedians,
I have just modified one external link on Long 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:
*Added archive https://web.archive.org/web/20061018063912/http://www.cocoadev.com/index.pl?MSDOSFileSystem to http://www.cocoadev.com/index.pl?MSDOSFileSystem
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 21:31, 5 January 2018 (UTC)
thread_title:  External links modified 

message: The 4690 OS link (reference 9) to IBM now (apparently since 6th Nov 2014) yields a document saying contact Toshiba for information.  — Preceding unsigned comment added by 217.169.14.20 (talk) 12:48, 21 April 2019 (UTC)
thread_title:  Broken links 

message: ... Also, one is more likely to encounter issues creating files or folders in the root directory, since FAT12 and FAT16 only allocate space for 512 root directory entries on hard disks. Since long filenames use more than one directory entry, this problem may occur with fewer than 512 files or folders in the root directory.[2] There is space only for 24 long filenames of maximum length (512/(1+20)). This problem does not exist for FAT32 volumes.
This is such a common misconcepton that I know anyone would be hard pressed to find a formatter that would allow you to configure the number.  The way around this for me anyways back in the day was to edit the disk afterwards with something like partition magic. 66.114.93.6 (talk) 22:17, 23 August 2020 (UTC)
thread_title:  limitations