Talk:Long filename
From Wikipedia, the free encyclopedia
 |
This article is within the scope of Computing WikiProject, an attempt to build a comprehensive and detailed guide to computers and computing. If you would like to participate, you can edit the article attached to this page, or visit the project page, where you can join the project and/or contribute to the discussion. | |
| ??? | This article has not yet received a rating on the quality scale. | |
| ??? | This article has not yet received an rating on the importance scale. | |
Contents |
[edit] microsoft as origin of long filename support
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)
[edit] Add "long filenames" redirect
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)
[edit] apart in the root directory
"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)
[edit] UPPERCASE / lowercase problems
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)
- See just above File_Allocation_Table#Third-party_extensions Platonides 21:22, 16 May 2007 (UTC)
[edit] Similar Implementation Section
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)
[edit] Spelling
- "Long filename (LFN) is the name given to the longer and therefore more descriptive filenames supported by the Microsoft FAT filesystem."
The name given by Microsoft is "long file name". As far as I know, the word "filename" is not used in regular encyclopedias, and it's not in the Merriam-Webster's Collegiate Dictionary.
Examples:
1) http://support.microsoft.com/kb/174456
"When you attempt to run a long file name (LFN)"
"Short File Name" "Long File Name"
3) http://www.merriam-webster.com/dictionary/filename .
[edit] Case Sensitivity
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)
- TomViza 12:14, 23 October 2007 (UTC)
