Jump to content

Talk:Long filename

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 66.114.93.6 (talk) at 22:17, 23 August 2020 (→limitations: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

WikiProject iconComputing C‑class Low‑importance
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
CThis article has been rated as C-class on Wikipedia's content assessment scale.
LowThis article has been rated as Low-importance on the project's importance scale.

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)

The article is not available for public reading.

37.47.37.21 (talk) 19:08, 11 June 2017 (UTC)[reply]

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)[reply]

Done. — EagleOne\Talk 16:22, 21 October 2006 (UTC)[reply]

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)[reply]

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)[reply]

See just above File_Allocation_Table#Third-party_extensions Platonides 21:22, 16 May 2007 (UTC)[reply]

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)

What does "Similar" mean here? Does the Mac File System store long names in a chain of short name records? I cannot find info that it does. If "Similar" only means "longer than 8+3" I suggest change section title to "Other File Systems supporting long filenames" or remove section. David A se (talk) 20:18, 31 March 2009 (UTC)[reply]

Quote "one of the first file systems to support long names and spaces was the Macintosh File System ... 1984". One might add that there was VAX/VMS: 9+3 chars (1979?) and 39+39 chars (≤1985?) (thou not spaces) and UNIX: 14 chars 1972. How much longer than 8+3 qualify as "long"? I suggest remove section (years and filename-lengths are tabulated in "Comparison_of_file_systems") David A se (talk) 20:18, 31 March 2009 (UTC)[reply]

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)[reply]
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)[reply]

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

2) http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/prork/prdf_fls_ggrm.mspx?mfr=true

"Short File Name" "Long File Name"

3) http://www.merriam-webster.com/dictionary/filename .

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)[reply]

Meaning of "long filename"

This article is confused about what "long file name" means:

  • Any method of supporting file names longer than 8.3 (the mention of NTFS in the lead). Then surely non-MS file systems would count too?
  • The specific implementation method of file names longer than 8.3 on the FAT system.

Most of the article seems to be about the latter, although the only MSDN reference I bothered to check (Naming Files, Paths, and Namespaces) talks about it as the first meaning. In that case, this article should be renamed something like "Long file names on FAT".

Also, the lead claims that the characters in a long file name are stored as unicode characters, whereas that reference implies that's only true for FAT32 (and NTFS, etc), not FAT or CDFS. On that note, maybe CDFS should be mentioned in this article too?

In summary, this article contains useful information, but it is not clear what it is about overall. Quietbritishjim (talk) 14:17, 19 January 2011 (UTC)[reply]

While the article is currently a bit Microsoft-centric, we have to distinguish between three cases:
  • Long filename support (in general), OS and FS independent -> this article Long filenames
  • Long filename support in the FAT filesystem (there are several ways to do it) -> FAT long filenames, redirecting to the corresponding section in the File Allocation Table article for the general macroscopic description
  • Long filename support in the FAT filesystem using the VFAT method -> VFAT long filenames, redirecting to the corresponding section in the Design of the FAT file system article, discussing the implementation details of the VFAT method. Similar sections for the implementation details of other FAT LFN methods could be added there, if we have enough information about them.
In other words, in the long run *this* article should become the generic article for long filenames in filesystems in general, the other two locations should discuss the FAT and VFAT specific stuff in better details.
--Matthiaspaul (talk) 23:57, 8 April 2015 (UTC)[reply]
1) May the article should be RENAMED to "FAT long filenames" or "Long filename for FAT file system"? or 2) Merge with another article? or 3) Subsection of a larger article. No matter the direction, a big change should be discussed and voted on, and give everyone plenty of time to state their opinion. • Sbmeirow • Talk • 05:39, 9 April 2015 (UTC)[reply]
This is just another in a repeated series of discussions over the years on this Talk page. Forgive me if I'm misapprehending this, but Matthiaspaul starts out completely correctly (the article is only about extending 8.3 FAT, as the article clearly states and as logic dictates) and then concludes wrongly (it's about everything in the world). There is no such thing as "long filenames in general" any more than there is "how long is a piece of string?". On normal filesystems (almost everything other than FAT), they're not called "long filenames"; they're called "filenames". Similarly, someone else had long ago suggested the title "Arbitrary selection of other file systems supporting more than 8+3 characters using different and mostly straightforward techniques". There is only the fact that MS-DOS is ludicrously and fairly uniquely crippled since MICROS~1 bought one guy's Quick-and-Dirty Operating System, renamed it to MS-DOS, and built an illegal monopoly to force anyone to have ever noticed it. The technology to extend FAT's 8.3 filenames never would have existed without this monopoly. Other contemporary filesystems with relatively short filenames, nevertheless have much longer filenames; and such entities had the decency and sense to relieve such limitations (where filename length would be amongst the least of all architectural concerns) by just creating new filesystems. By actually, legitimately advancing. This is just another article about how Microsoft set the world 20 years back into a particularly crappy area of the stone age. Furthermore, we're tangientially acknowledging other FAT-based standards for extending filename lengths (such as OS/2's EAs), so as to distinguish them from the main one. And then after the era of VFAT, I don't know if Microsoft progressed the FAT32 and xFAT lineage so that the length of filenames was native rather than a backward compatible workaround. So yes, as with so many other times that this misconception has been corrected on this talk page and in the article, there is no problem whatsoever and the article's content is correct as it is. However, as Sbmeirow says, it could be specified as "FAT long filenames" where Microsoft's is the most sadly notable and detailed example. And if there was a merge, all I know of offhand would be to import Design_of_the_FAT_file_system#VFAT, because isn't that redundant? Isn't "Microsoft's standard of FAT long filenames" called (or synonymous with) "VFAT"? Thank you. And good job on the article, guys. — Smuckola(talk) 12:22, 9 April 2015 (UTC)[reply]

MAX_PATH

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)[reply]

Example in Limitations

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)[reply]

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:

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

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: 5 June 2024).

  • 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) 21:31, 5 January 2018 (UTC)[reply]

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)[reply]

limitations

... 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)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Long_filename&oldid=974599902"