Talk:File Allocation Table/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Archive 6

Long filenames

This is a good article about a complex subject. But even though it is big, it needs more details about LFNs. It would be good if we could deal with LFN details in the separate article, but right now it is very short on tech details, and it does sort of make sense for them to be here, in the context of FAT details. *** What algorithm does each version of windows use to generate 8.3 names? 98 seems to just use FILSIX~n and count up. XP starts that way, but then takes off and generates much odder forms. Under what situations does each version of Windows just use 8.3, with no LFN? How can the presence or absence of a LFN form be seen by the user? Does each version of Windows treat 8.3 names the same? 98 seems to treat them as UPPERCASE, XP seems to treat them as lowercase, which seems to mess up filestructures when files are moved from XP to 98 via FAT USB flash drive. Is this true? Where is it documented? How to deal with the problem? Archives seem to store only the LFN, not the 8.3? The 8.3 would be regenerated by the receiving FAT when the archive is unpacked? So the 8.3 could change -- is this a problem? 69.87.203.23 00:07, 23 January 2007 (UTC)

Media descriptor

The Boot Sector section has a table within a table (the BPB) that lists Media decriptor values however this seems rather idealistic and incorrect. Please refer to Microsoft's Knowledge Base article on Standard Floppy Disk Formats Supported by MS-DOS. Uzume 08:55, 23 January 2007 (UTC)

I edited the list according to MS-DOS Programmer's Reference. It hopefullly gives a little less idealistic definition for the values also pointing what to use for media outside these antique medias.Marko 15:05, 28 August 2007 (UTC)

FAT24 - does it exist?

I remember to have seen in Norton Disk Editor a FAT24, but I don't see it in this wikipage. Does it exist? —The preceding unsigned comment was added by 82.188.163.3 (talk • contribs) 2007-03-21T11:24:41 (UTC)

Google gives 1,700 matches for FAT24, many of which are company names or dietary numbers (like fat24, carbs37, protein7). Compare that to almost 2 million for FAT16 and over 6 million for FAT32. FAT24 appears to be misused (like here) when applied to filesystems, some thinking it is a big FAT16 (that is, over 32 MiB). FAT24 is not an official standard. Norton might support it just because it could be of use to someone, somewhere writing a custom filesystem. Or using it to view tables of 24 bit values and not a filesystem at all. —EncMstr 15:34, 21 March 2007 (UTC)

FAT32 Maximum File Size Discrepancy

The chart on the right side of the page lists FAT32 "Max file size" as 2GiB, but later, under the "FAT32" section it says "The maximum possible size for a file on a FAT32 volume is 4 GiB minus 1 Byte (232−1 bytes)." I was under the impression that it is 4GiB and that seems to check out. Anyone know better than I do? -Austin

DOS 2.0 etc

http://support.microsoft.com/kb/67321 "In the past, some OEMs have modified their versions of MS-DOS to support other sector and/or cluster sizes. The Microsoft MS-DOS 5 Upgrade Setup will, if possible, convert the logical drive to MS-DOS 5.0 compatible. This entails converting the sector size to 512 bytes while retaining the nonstandard cluster size."

http://support.microsoft.com/kb/69912/ MS-DOS 3.0 supports partitions larger than 15 MB using a 16-bit FAT, which allows a smaller cluster size and more efficient disk usage. As a result, MS-DOS 2.x hard disks larger than 15 MB are incompatible with later versions of MS-DOS. Fdisk creates only one MS-DOS partition per drive.

DOS allowed you to install block devices, ie file systems, in system.ini (normal .sys device drivers are not block devices). This was normally used in DOS 2.11 to support 40MB disks. You installed the other partitions as non-dos partitions, using something other than Fdisk. The installable device driver accessed the other partitions and made them available to DOS. The other partitions were normally (always?) formated using DOS format as FAT drives. I think that the second ref. is refering to OEM variations like in the first ref, but I don't know. Does anyone remember using a block device or large disk in DOS 3.0? (david) 218.214.18.240 12:40, 10 June 2007 (UTC)

Under 'Extended partition and logical drives' section

In this section (on 14 June 2007), we find the sentences:

"The logical drives were described by on-disk structures which closely resemble the Master Boot Record (MBR) of the disk (which describes the primary partitions), probably to simplify coding, and they were chained/nested in a way analogous to Russian matryoshka dolls."

The underlined portion would be a visually appealing analogy, if it were true, but it's not. Logical drives have never been enclosed within each other (as per the doll analogy); only within the one single Extended partition, like items placed side-by-side within a single box! Since some might object to a quick removal the original idea, I decided to place a record here before eventually altering it. Reading the article Extended Boot Record (and the data posted to its Talk: page about these concepts), should convince anyone this is necessary. Daniel B. Sedory 01:49, 15 June 2007 (UTC)

• Since no one has commented on this for some time, I'm finally going to alter the text to reflect that nested partitions are not what an OS or partitioning utility normally create. I'll try to leave the analogy in the text however. Daniel B. Sedory 18:40, 4 August 2007 (UTC)

---

"It was not possible to create multiple DOS partitions using DOS tools and third party tools would warn that such a scheme would not be compatible with DOS." (29 December 2007)

The first part is true: the second part is not.

That is, no doubt there were also third party tools and operating systems that produced partitions which were not compatible with DOS, but why mention them here? DOS had support for installable block devices. Third party installable block devices were sold (or bundled with drives) to support the large drives. They were designed to be installed with DOS, and sold for that purpose. Disk letter assignment followed the DOS standard for assignment of disk letters to block devices: there was no ambiguity, and these partitions could not be used to boot DOS.

Later, DOS 3.x introduced native support for larger drives.

No doubt this was "a good thing", so you can't assume that DOS 3.x was created only to squeeze the third party competition, but you have to keep in mind that there was a standard support in DOS 2.x for block drivers, and lots of people did buy larger disks and use them.

Regarding the warnings about compatibility, I wonder if you are confusing that with later warnings, after DOS 3.x already had support native support for large disks? Boot Sector device drivers became popular that replaced the BIOS. Those disks were not 'compatible with DOS' because no block driver was provided: if you lost the boot sector, or didn't boot from the right boot sector, you had to load a Windows driver to access the disk. Another possibility is that you are thinking about Xenix or Novel drivers: they weren't compatible with DOS.

The bottom line is that large disks sold for use with DOS 2.1 and 2.2 required a device driver loaded in config.sys. That's all. The system was not disfunctional.218.214.18.240 (talk) 08:38, 29 December 2007 (UTC)

Max size

Maximum size a file should be 4GB minus 2 bytes. edit: Put this to the test. Max file size is 4GB, but will not store at 4GB, Max size a file can be is 4GB minus 1byte (which will take up 4GB) Heres a reference screenshot i took File:Fatmaxsize.png

http://www.ntfs.com/ntfs_vs_fat.htm AbsoluteMSTR 05:42, 20 June 2007 (UTC)

Flaws and limitations section should be added

There should be a separate section dedicated to the flaws and limitations of FAT32, which would summarize the mentioned limitations that are scattered throughout this article, add some that are not mentioned, and detail the ramifications of those issues. For instance it would explain how FAT32's file name illegal character set creates limitations on its cross-platform compatibility, which makes it a poor choice of format for disks that are going to be used on a network with any non-MS operating systems.

FAT on Flash

I made an edit a few days ago adjusting a sentance in one of the start paragraphs which claimed FAT was "ideal for flash". FAT is appalling for flash, and for reasons alredy explained in the article. My change was reverted with the comment "I know no reasons for FAT being pathological on flash"!

FAT is very bad on flash because FAT is block based and when the FAT blocks are smaller than the flash blocks, the entire flash block has to be fully read and rewritten just to add one FAT block. This means that as the device becomes fuller, performance asymptomatically approaches zero.

If no one objects, I will reapply my change.

Toby Douglass 12:04, 17 July 2007 (UTC)

Your comment that "the entire flash block has to be fully read and rewritten just to add one FAT block" makes me think you're talking about FAT on top of raw flash memory. That would be pathologically bad, but no one uses FAT that way. Your comment that "as the device becomes fuller, performance [asymptotically] approaches zero" makes me think that you're talking about the block device emulation on consumer flash drives. This is a real problem, but it has nothing to do with FAT or whatever other file system you layer on top of the virtual block device. You can't use a flash file system on (the vast majority of) these drives because they don't expose the underlying hardware. It makes no sense to say that FAT is pathologically bad on flash drives when every other file system either exhibits the same pathology or can't be used at all. -- BenRG 15:57, 17 July 2007 (UTC)

Explain how FAT is used on flash. As I understand it, that IS how it is used. How else can it be used?

Performance loss as the drive becomes full has everything to do with FAT; if FAT was not block based, it would not occur. FAT is responsible for this behaviour due to its design. It is an inappropriate filesystem for flash.

I demur; if all filesystems are pathologically bad, then they are, and should be said to be. It is incorrect to avoid saying FAT is pathologically poor because all other filesystem are also poor. Furthermore, not all filesystems are poor in this way. Non-block based filesystems do not exhibit this behaviour. Toby Douglass 20:03, 17 July 2007 (UTC)

Flash has to be erased in big chunks, but it doesn't have to be written in big chunks. When a request comes in to write a (512-byte) block, it's written to an empty block-sized portion of flash memory, and the location is stored in a logical-to-physical block mapping table. If the block was previously stored somewhere else, that location is tagged as superseded. When a flash erasure bank contains only superseded blocks, it's erased and those slots marked as empty. If the space is fragmented enough then this may stop happening, in which case you have to move data. I don't know how this is dealt with in practice, but I assume consumer drives have more internal memory than they expose. As far as I know, all consumer flash drives do this translation internally (CF, SD, USB keys, solid-state IDE drives, etc.). You can't run a flash file system on these drives, because they don't let you write directly to the flash memory. There's no way to know how the logical block numbers are mapped to physical locations. -- BenRG 10:23, 18 July 2007 (UTC)

TechNet Magazine Articles

This article, [1], is suspect because according to Raymond Chen '[My Windows Confidential] "published articles" are just blog postings in dead tree form. So it's all the same.' If such is to be believed, then all TechNet Magazines articles should be suspect, since apparently TechNet Magazine's editor allows blog-quality gossip and speculation to make it into their magazine without disclaimers.

Characters are not Bytes!

In many places in the article, it refers to filenames being 255 bytes long, that is incorrect. Each character in a long file name is 16 bits in size, so the maximum size of a long file name is more like 512 bytes (assuming a 16-bit null terminator).

I'm not sure whether the encoding is UTF-16 or UCS-2 though. --Dwedit 12:44, 17 August 2007 (UTC)

NT originally used UCS-2, but this was "reinterpreted" as UTF-16 at some point (Windows 2000?). This probably applies to VFAT file names also. -- BenRG 00:02, 19 August 2007 (UTC)

0xF8 - Hard disk. Single sided, 80 tracks per side, 9 sectors per track => Doesn't make sense.

http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/prork/prcb_dis_stfl.mspx "A value of 0xF8 indicates a hard disk"

Wikipedia page: "0xF8 Hard disk. Single sided, 80 tracks per side, 9 sectors per track"

I think the parameters seems "kind of" non realistic? (unless CHS is somehow encoded within the media descriptor byte)

https://users.cs.jmu.edu/abzugcx/public/Student-Produced-Term-Projects/Operating-Systems-2005-FALL/MS-DOS-%26-PC-DOS-by-Lindsey-Buranych-Alan-Crouch-Matthew-Letnaunchyn-Sandra-Saab-Carl-Shapiro-2005-Fall.doc (crappy word file use http://www.google.com/ to view as html) Says "0xF8 Single sided, 80 tracks per side, 9 sectors per track"

But it still doesn't make sense. I think someone have to put some more consistent explanation to mediabyte = 0xF8. Electron9 18:49, 18 September 2007 (UTC)

Long File Name Attributes

Many web sources such as http://home.teleport.com/~brainy/lfn.htm say that long file name entries have attributes volume_label+hidden+archive. This article says only volume_archive. Which is correct and can you cite a reliable source for your answer?

Kitplane01 17:33, 10 October 2007 (UTC)

ext3 table

is ext3 table the same as fat32 table?Tuxthepenguin933 20:14, 25 October 2007 (UTC)

Tux..., where have you ever seen the phrase "ext3 file allocation table?" Short answer: No! ext3 is a very different file system compared to Microsoft's FAT16 or FAT32 file systems. Used primarily by *nix OSs, such as Linux, ext2 and ext3 have what are called "inodes" that are dispersed throughout their partitions; ext3 uses journaling just as advanced as the NTFS file system! Click on "inodes," "ext2" and "ext3" in the sentence above for more info. Daniel B. Sedory 05:56, 26 October 2007 (UTC)

what i mean is ext3 and fat32 use a table for its directory contents so does that mean they are both the same in speed?--Tuxthepenguin933 13:23, 26 October 2007 (UTC)

What do you mean by "table" and "directory contents"? Fat32 directories are simple lists of files. Ext3 uses a weird hash-table format which makes it much faster for large directories. -- BenRG 17:32, 27 October 2007 (UTC)

Boot Sector vs. BIOS Parameter Block

According to this MS White Paper on FAT, the Boot Sector is only composed by 11 bytes. Then comes the BPB which has 25 bytes. And then comes extended information for FAT16/FAT32. In this article, all the first 36 bytes are listed as Boot Sector. How come? --Franciozzy (talk) 20:50, 17 November 2008 (UTC)

I just took a look at the microsoft document in question and it talks about "A bios parameter block in the boot sector". I would interpret that as meaning the whole sector is the "boot sector" and the BIOS parameter block is part of it. Can you tell us preceisely what part of that document you think is claiming the boot sector is only 11 bytes? Plugwash (talk) 03:54, 19 November 2008 (UTC)

Hi! I think that MS itself doesn't clarify this enough. They actually say, and I quote: "The first important data structure on a FAT volume is called BPB <...>. This sector is sometimes called the boot sector or the reserved sector ...". Later on, there's a table entitled "Boot Sector and BPB Structure". If you have a look at the name of the fields, you will notice that the first two fields are BS_jmpBoot (3 bytes) followed by BS_OEMName (8 bytes). All the following fields (25 bytes) start with "BPB_". After that, there's more BPB_ elements for FAT32. Regardless of the FAT type, there's still some other "BS_" fields at the end. I believe you are right when saying the BPB could be contained in the BS (specially with those BS elements at the end), but I also believe that this is sort of open to improvement because the Wikipedia article mentions only the BS and then an extended BPB. What do you think? Franciozzy (talk) 16:23, 19 November 2008 (UTC)

Maximum FAT32 format in WinXP

Hey all. I dont have much experience in Win2k but I have, many times, formatted a 120GB drive with FAT32 in WinXP. It needs to be done from the Microsoft Management Console as far as I've seen, but it is possible.

Same here. I just used the FORMAT command on 250GB drive in fat32. Some of the confusion might be different front-ends: command-line, MMC drive manager, wizard? I also speculate that the restriction may have been lifted at some time (via updates), not per OS version. —Długosz (talk) 03:23, 13 February 2008 (UTC)

Then again, it did not work! It was happily formatting, but I didn't want to wait 6 to 10 hours, so I broke out and did a /q format. It complained that the partition was too large. Would the non-quick format have complained after writing all the sectors?!

Meanwhile, in contrast to the report from the anonymous poster above, the MMC "Drive Manager" snap-in did not give any choice other than NTFS. I found [2] and worked on Vista. —Długosz (talk) 04:50, 13 February 2008 (UTC)

Unless i've missed something, none of the tools that come with Win2k will allow you to format a FAT-32 volume larger than 32GiB. It will, however, handle existing volumes without a hitch. I gather that the reasoning behind the restriction is that FAT-32 starts becoming inefficient beyond 32GiB. But it still works. (And i find the single 55GiB volume on my external much more convenient than a pair of smaller ones would be, and any performance hit negligible.) I give MS one of those rare thumbs up, if they relaxed the restriction under XP.
—überRegenbogen (talk) 20:48, 11 August 2008 (UTC)

The article has one piece of history wrong, even though you might even find a reference for it: the real reason fat 32 format size was limited wasn't because of scandisk, or any real technical reason. It was because at the time, the windows NT filesystem team had an inferiority complex and wanted this competing abomination dead. Any reasoning you hear is simply excuses they made up so they wouldn't be threatened.--someone

Maybe true, but FAT(32) is slower than NTFS on large files. As the articles states, free space is expensive to find in FAT (thus to calculate remaining free space is very expensive) and fragmentation is high. Those are also reasons not to use FAT on large volumes. Dtech (talk) 12:59, 5 April 2009 (UTC)

Errors in file system information at ntfs.com

Tarun just changed the file size limits on FAT32 and FAT16 to 4 GiB − 2 bytes and 2 GiB respectively on the basis of this table (I assume) at ntfs.com. I've just verified that this is incorrect by creating a >2 GiB file on a FAT16 volume with 64K clusters and a 4 GiB − 1 byte file on a FAT32 volume, using WinXP Pro SP2. Here are some other mistakes I noticed, while I'm at it:

• Long file names on FAT12 aren't limited to 254 characters (verified).
• Long file names on FAT aren't limited to the "system character set", assuming that means the system code page (verified). I think this is true on Win9x, but that's an operating system limitation that applies to all file systems, including NTFS volumes mounted over the network.
• The number of files on a volume is not limited to 4194304 on FAT32 or 65536 on FAT16 (verified).
• No OS that I know of limits FAT32 volumes to 32 GiB. It's a limitation of some Microsoft formatting tools, not of the filesystem implementation.
• NTFS volumes are not limited to 2 TiB.

-- BenRG (talk) 17:13, 3 February 2008 (UTC)

ExFAT File Size Limit

According to MSDN, there is no 4 GiB file size limit on ExFAT file systems. See http://msdn2.microsoft.com/en-us/library/aa914353.aspx However, I'm not sure what the actual limit is.
Vfs (talk) 17:26, 9 March 2008 (UTC)

The article says now that exFat has "support for files up to 2⁶⁴ bytes". — Wenli ^{(reply here)} 02:27, 30 May 2008 (UTC)

Proposed Change: slightly misleading statement about impact of fragmentation of solid state media

The 3rd paragraph in the introduction says:

[...] fragments tend to become scattered over the entire disk, making reading and writing slower. [...] . Due to a limited number of lifetime writes, and their quick access times, solid-state memory cards should usually not be defragmented.

The last sentece should be changed to:

Solid-state memory (such as flash memory cards or flash usb sticks), should not be defragmented. They don't suffer speed degradation by fragmentation due to their design. Additionally running a defragmentation program will reduce the lifetime of these media by using up a significant number of their limited number of write cycles.

Reason:

I think the original statement is a bit misleading in implying that solid state disks will, at least to some extent, suffer read/write speed degradation from fragmentation. This is not the case. The reduced speed is a direct result of the access latecy due to the movement of the read/write heads of magnetic and optical media. Reading is only significantly slower if fragments are in different tracks (rotational delay might also have an effect but that is significatly less). Due to the design of solid state media, their access time is the same for each cluster, regardless where it is stored. Viper144 (talk) 18:18, 15 June 2008 (UTC)

I agree that's the primary reason. However, sequential contiguous sectors inspire increased efficiency in other ways. One is because some driver code (such as FAT drivers I've written) looks for opportunities to reduce the number of kernel read operations by increasing the size of a read if subsequent linked clusters are sequential. —EncMstr (talk) 20:51, 15 June 2008 (UTC)

Also in the case of fat reading a fragmented file requires reading more sectors of the file allocation table (for a badly fragmented file it may require reading a sector of FAT for every sector of data!). So it will be slower even on media where all sectors cost the same to read. Plugwash (talk) 13:36, 18 June 2008 (UTC)

Of course fragmentation makes Flash drives slower: they have optimised read routines which read much faster than the read speed of a cell, by doing the setup sequentially (pipelining), just like the RAM in your computer does. Is this slow enough to measure? It would be if you were reading individual bytes at random locations, but probably not when reading sectors. —Preceding unsigned comment added by 218.214.18.240 (talk) 09:32, 28 February 2009 (UTC)

Binary Units

Shouldn't all the filesystem limits be listed in kib, MiB, GiB and TiB? These limits naturally come from the number of bytes you can address with integers of certain length so i'm pretty sure it would be binary limits. —Preceding unsigned comment added by 98.213.141.241 (talk) 01:35, 2 July 2008 (UTC)

I agree. In several of the computer-related articles, attempts to implement that have been reverted with the reasoning that the manual of style doesn't endorse binary units. It should be straightened out first before fixing the articles again. —EncMstr (talk) 01:53, 2 July 2008 (UTC)

The deprecation of IEC units was introduced on 7 June 2008, despite a clear consensus against such deprecation. Thunderbird2 (talk) 15:03, 5 July 2008 (UTC)

Not true. The text you, TB2, refer to was put there with consensus, the link you provided claiming "despite a clear consensus" misrepresents the truth of where the consensus is. This is because firstly votes (the link you provided is nothing but a vote) don't make consensus, good arguments make consensus. Secondly the real consensus is here. Thirdly the vote you cite is old. At the time you did not present substantive arguments and you have still have not provided substantive arguments. The consensus is actually for the text in MOSNUM which includes the deprecation of IEC prefixes for the many good reasons given in the link I have provided. Fnagaton 16:38, 5 July 2008 (UTC)

Now back on topic. The IEC prefixes KiB, MiB etc should not be used in this article because they are not used by the sources we cite, they are unfamiliar and therefore confuse readers and because of WP:UNDUE we have to use terms that are used by the real world. Obviously IEC prefixes are not commonly used in the real world, so we don't use them here either. What is much more familiar and easily understood by the average reader is to state the specific number of bytes used for a quantity. The average reader understands the number 1024 much better than KiB. One of the goals of disambiguation is to help clarify, not to cause more confusion. The last time I checked the goals of disambiguation did not include the promotion of virtually unused IEC prefixes. Fnagaton 16:41, 5 July 2008 (UTC)

Should MOSNUM continue to deprecate IEC prefixes?

A discussion has been started at WP:MOSNUM concerning the continued deprecation of IEC prefixes. Please comment at the MOSNUM talk page. Thunderbird2 (talk) 19:15, 5 July 2008 (UTC)

Simple Error

Shouldn't this:

"Common implementations have a serious drawback in that when files are deleted and new files written to the media, directory fragments tend to become scattered over the entire disk, making reading and writing slower on storage devices, which have lower seek time for random data access (Such as mechanical hard drives)."

Be:

"Common implementations have a serious drawback in that when files are deleted and new files written to the media, directory fragments tend to become scattered over the entire disk, making reading and writing slower on storage devices, which have higher seek times for random data access (Such as mechanical hard drives)."

After all, why would it be worse if fragmentation happened on a drive that dealt with it better (lower seeks times are better for fragmented drives).70.62.232.146 (talk) 18:32, 15 July 2008 (UTC)

What about saying "making reading and writing slower on mechanical storage devices (such as hard disk drives), for which access to random locations on the disk requires more head movements, hence increased seek time." 82.67.122.43 (talk) 20:33, 19 July 2008 (UTC)

A bit long-winded. The simplest and least confusing fix that leaps to mind is "which have longer seek times"
—überRegenbogen (talk) 21:03, 11 August 2008 (UTC)