![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
"which limited the maximum space of the filesystem to approximately 32MB of space (however this is far more than a typical 360KB floppy could hold at t"
Are these megabytes and kilobytes or mebibytes and kibibytes? - Omegatron 02:44, Jan 22, 2005 (UTC)
For the time being, I've commented out the bit in the history section about FAT being invented in 1963. Unless someone can confirm this, it should be removed entirely. I've also nominated the article Bill Fikes for deletion, and suggest that the matter be debated at Wikipedia:Votes for deletion/Bill Fikes.- gadfium 02:52, 18 May 2005 (UTC)
Need to check that this is "still in the linux kernel" -- I think if it has not already been removed then it is in the process of removal.
Can someone please add information to the article about the X-Box variation of the FAT filesystem?
Although there are no official documents, as far as I know, there are a lot of reverse enginering and for article enrichment that information should be there.
-- Claunia 05:25, 16 Aug 2005 (GMT)
This article currently has 3 infoboxes which give a lot of duplication and make it hard to compare the figures given for the 3 versions of fat. imo we should subst them and then merge them into a single table what do others think. Plugwash 03:14, 30 August 2005 (UTC)
People come to this page to read about the FAT filesystem, why should they have to refer to another page to find out basic information? The three infoboxes here aren't intended for people to make comparisons between FAT12/16 & 32. They were just created because the infobox doesn't easily allow for having all three in the one infobox. Which is probably my fault since I started the infobox. If someone else doesn't get to it first, I'll eventually get around to tidying up the infobox and this page so there is only one infobox here. AlistairMcMillan 13:56, 1 September 2005 (UTC)
"It has a serious drawback in that when files are deleted and new files written to the media, the files can become scattered over the entire media making reading and writing a slow process. De-fragmentation is one solution to this, but is often a lengthy process in itself and has to be repeated regularly to keep the FAT file system clean."
Well, this just happen with EVERY and EVERY filesystem everywhere, and is just a matter of the implementator on how to prevent this as possible. It's not a FAT only problem and I think it should be removed and put instead in Filesystem article. Just it is famous because Microsoft implementations of FAT just take no care on fragmentation.
— Claunia 21:20, 8 September 2005 (UTC)
Thanks for mixing the infoboxes.
Just, DR-DOS added support for FAT32 in version 8.0. I have no access nor to binaries nor to documentation of this version, so I don't know if they still support volume encryption, but I think it doesnt. If you get access to that version, check it. — Claunia 21:05, 8 September 2005 (UTC)
What I ran into with FAT12 is that by default, Windows 2000 and Windows XP will format storage media that isn't a hard drive, smaller than 32MB (don't get me started on the MiB thing ;-), as FAT 12. That includes the majority of solid state memory cards labled "32MB" because their formatted capacity is less than 32 megabytes. The user is only presented with the "FAT" option in the Windows GUI.
How I discovered this (though I'm sure it was known to many others at the time ;-) was when I wanted to save time deleting songs from a 32MB MMC in my MP3 player by formatting the card instead of selecting and deleting all the songs. The player could no longer read the card! I then tried forcing it to FAT16 from a command line and the command reported that it was formatting FAT12 in spite of my command switch to use FAT16. I had to hunt up a system running Windows Me to plug the player into to reformat the card to FAT16, whence it again worked in the player. (The player could tell there were files on the card in FAT12 but could not play them.)
Is there a way to forcibly format a sub-32MB piece of storage media as FAT16 in Windows 2000 and XP?
There's another FAT "gotcha" in Windows XP where the default for storage media over a certain size is FAT32, but it's not a problem like the sub-32MB FAT12 issue because the user can just select FAT. (Does Windows 2000 do this too?)
Does anyone know why Microsoft "resurrected" FAT12 for non-floppy storage media with Windows 2000 and XP? It is a nasty problem for devices that use smaller media, can use only FAT16 and do not have the built in capability to format their own media, or can, but only if the card is totally blank or already FAT16.
I think, it was removed in Me or 98 S.E., can anyone check? Claunia 14:14, 9 October 2005 (UTC)
As seen on Plugwash's talking and in it comment in the article, we have no proof that FAT supported ANY kind of ADS inside NT.
We all know that it supported EAs under OS/2 in the "EA DATA.SF " file in root, and I have checked that Windows 2000's Services for Macintosh indicates that Macintosh Finder Info and Macintosh Resource Fork get lost when moving to a FAT32 drive.
However I'll investigate further in this issue as soon as possible, on if older SFMs support ADS on FAT drives and if NT can copy EAs to/from FAT drives.
— Claunia 16:59, 26 October 2005 (UTC)
User Adam Mirowski recently added this sentence to the article, with the edit comment "(added a possible justification for fat32 "crippling". The whole paragraph is not quite NPOV)"
Here's why I removed it: it does not address the question of why Microsoft prevented users from creating FAT32 partitions larger than 32 GB, when the system supports much larger partitions. This certainly gives the impression of an artificial restriction. I agree that the unattributed statement that Microsoft is "often accused of deliberately crippling FAT32 support" is a problem, and have replaced it with a sourced opinion from Peter Norton.
The sentence would be relevant if it were widely held that NTFS was unneeded and that FAT32 could have sufficed had Microsoft not "crippled" it. That's not the issue, though. The question is not whether NTFS has real advantages over FAT32. The question is why did Microsoft apparently put in an artificial limitation that makes FAT32 less useful than it could be.
Certainly, if someone has a verifiable source that says there is a good reason for restricting FAT32 to 32 GB, that should be added to the paragraph as well. Dpbsmith (talk) 16:37, 23 February 2006 (UTC)
Anyone know if it could also read/write standard PC disks? Plugwash 21:26, 25 February 2006 (UTC)
though some badly behaved tools managed to introduce it, anyone like to clarify? Plugwash 14:39, 12 June 2006 (UTC)
The FAT32 boot sector information was completely missing, as many have pointed out before but no one fixed.
So, since I'm currently writing software dealing with these structures, I've added the information as much as I was concerned with it. There's still some things missing, such as what the File System Information Sector is about, and what some other fields contain (Flags, Version, etc.). Yet, at least it should be easier to add such information now that the table has been separated into parts for FAT12/16 and FAT32.
Also, this discussion page is way too big. I've removed some parts that appear to be handled now by my changes or are old Q&As that do not need to be here any more.
Tempel 14:52, 12 June 2006 (UTC)
Are there any sources giving the definition of attribute bit 6 (0x40) as "device"? I haven't been able to find anything online; the Microsoft FAT32 spec simply says "reserved". (It certainly seems to have some meaning to Windows; editing a directory entry to set bit 0x40 leads to an "access denied" file in WinXP.) -- Jkew 22:16, 27 July 2006 (UTC)
The article says:
I fail to fully understand this complaint, since individual swap files are limited to 4GB anyway, even on NTFS.
I think this entire paragraph should be removed, since:
I have rewritten the paragraph to indicate that only a decreasing portion of the population is restricted by the FAT32 limits, which is, of course, true for any product (namely, consumer Windows) which is no longer on the market. -- Scott McNay 01:30, 30 July 2006 (UTC)
"Bad blocks: linked list" is wrong, surely -- there's no list of bad clusters, just a bad cluster mark in the FAT for each one. -- Jkew 19:23, 1 September 2006 (UTC)
This got me thinking - See Hierarchical_File_System. There the structure for bad blocks is said to be a B*-Tree, while here (for FAT) it's said to be a linked list.
I find both descriptions misleading. In particular, for HFS, the bad blocks, while being somehow ending up in a B-Tree, is not specific enough (I hope you'd agree that saying that the structure for bad blocks is a sequence of bytes is eventually correct as well, but not specific enough). In fact, the way to mark bad blocks in HFS+ is by making them property of a specific "bad blocks file" (how is it done in HFS Standard, I do not remember?). And I think that's what should be the description in the HFS and HFS+ pages, instead of the current unspecific "b-tree" statement.
On the same level, bad blocks on a FAT FS are marked as individual clusters, inside the allocation table (versus being marked as a specific file using a linked list).
Only that way the distinctiveness of the different ways to mark bad blocks on these file systems becomes clear.
Agreed? -- Tempel 08:16, 3 September 2006 (UTC)
The article says "The FAT32 formatting support in Windows 2000 and XP is limited to drives of 32 gigabytes", but surely it should be volumes of 32 GB, not drives? AnonMoos 01:26, 4 October 2006 (UTC)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 1 | Archive 2 | Archive 3 | Archive 4 | Archive 5 |
"which limited the maximum space of the filesystem to approximately 32MB of space (however this is far more than a typical 360KB floppy could hold at t"
Are these megabytes and kilobytes or mebibytes and kibibytes? - Omegatron 02:44, Jan 22, 2005 (UTC)
For the time being, I've commented out the bit in the history section about FAT being invented in 1963. Unless someone can confirm this, it should be removed entirely. I've also nominated the article Bill Fikes for deletion, and suggest that the matter be debated at Wikipedia:Votes for deletion/Bill Fikes.- gadfium 02:52, 18 May 2005 (UTC)
Need to check that this is "still in the linux kernel" -- I think if it has not already been removed then it is in the process of removal.
Can someone please add information to the article about the X-Box variation of the FAT filesystem?
Although there are no official documents, as far as I know, there are a lot of reverse enginering and for article enrichment that information should be there.
-- Claunia 05:25, 16 Aug 2005 (GMT)
This article currently has 3 infoboxes which give a lot of duplication and make it hard to compare the figures given for the 3 versions of fat. imo we should subst them and then merge them into a single table what do others think. Plugwash 03:14, 30 August 2005 (UTC)
People come to this page to read about the FAT filesystem, why should they have to refer to another page to find out basic information? The three infoboxes here aren't intended for people to make comparisons between FAT12/16 & 32. They were just created because the infobox doesn't easily allow for having all three in the one infobox. Which is probably my fault since I started the infobox. If someone else doesn't get to it first, I'll eventually get around to tidying up the infobox and this page so there is only one infobox here. AlistairMcMillan 13:56, 1 September 2005 (UTC)
"It has a serious drawback in that when files are deleted and new files written to the media, the files can become scattered over the entire media making reading and writing a slow process. De-fragmentation is one solution to this, but is often a lengthy process in itself and has to be repeated regularly to keep the FAT file system clean."
Well, this just happen with EVERY and EVERY filesystem everywhere, and is just a matter of the implementator on how to prevent this as possible. It's not a FAT only problem and I think it should be removed and put instead in Filesystem article. Just it is famous because Microsoft implementations of FAT just take no care on fragmentation.
— Claunia 21:20, 8 September 2005 (UTC)
Thanks for mixing the infoboxes.
Just, DR-DOS added support for FAT32 in version 8.0. I have no access nor to binaries nor to documentation of this version, so I don't know if they still support volume encryption, but I think it doesnt. If you get access to that version, check it. — Claunia 21:05, 8 September 2005 (UTC)
What I ran into with FAT12 is that by default, Windows 2000 and Windows XP will format storage media that isn't a hard drive, smaller than 32MB (don't get me started on the MiB thing ;-), as FAT 12. That includes the majority of solid state memory cards labled "32MB" because their formatted capacity is less than 32 megabytes. The user is only presented with the "FAT" option in the Windows GUI.
How I discovered this (though I'm sure it was known to many others at the time ;-) was when I wanted to save time deleting songs from a 32MB MMC in my MP3 player by formatting the card instead of selecting and deleting all the songs. The player could no longer read the card! I then tried forcing it to FAT16 from a command line and the command reported that it was formatting FAT12 in spite of my command switch to use FAT16. I had to hunt up a system running Windows Me to plug the player into to reformat the card to FAT16, whence it again worked in the player. (The player could tell there were files on the card in FAT12 but could not play them.)
Is there a way to forcibly format a sub-32MB piece of storage media as FAT16 in Windows 2000 and XP?
There's another FAT "gotcha" in Windows XP where the default for storage media over a certain size is FAT32, but it's not a problem like the sub-32MB FAT12 issue because the user can just select FAT. (Does Windows 2000 do this too?)
Does anyone know why Microsoft "resurrected" FAT12 for non-floppy storage media with Windows 2000 and XP? It is a nasty problem for devices that use smaller media, can use only FAT16 and do not have the built in capability to format their own media, or can, but only if the card is totally blank or already FAT16.
I think, it was removed in Me or 98 S.E., can anyone check? Claunia 14:14, 9 October 2005 (UTC)
As seen on Plugwash's talking and in it comment in the article, we have no proof that FAT supported ANY kind of ADS inside NT.
We all know that it supported EAs under OS/2 in the "EA DATA.SF " file in root, and I have checked that Windows 2000's Services for Macintosh indicates that Macintosh Finder Info and Macintosh Resource Fork get lost when moving to a FAT32 drive.
However I'll investigate further in this issue as soon as possible, on if older SFMs support ADS on FAT drives and if NT can copy EAs to/from FAT drives.
— Claunia 16:59, 26 October 2005 (UTC)
User Adam Mirowski recently added this sentence to the article, with the edit comment "(added a possible justification for fat32 "crippling". The whole paragraph is not quite NPOV)"
Here's why I removed it: it does not address the question of why Microsoft prevented users from creating FAT32 partitions larger than 32 GB, when the system supports much larger partitions. This certainly gives the impression of an artificial restriction. I agree that the unattributed statement that Microsoft is "often accused of deliberately crippling FAT32 support" is a problem, and have replaced it with a sourced opinion from Peter Norton.
The sentence would be relevant if it were widely held that NTFS was unneeded and that FAT32 could have sufficed had Microsoft not "crippled" it. That's not the issue, though. The question is not whether NTFS has real advantages over FAT32. The question is why did Microsoft apparently put in an artificial limitation that makes FAT32 less useful than it could be.
Certainly, if someone has a verifiable source that says there is a good reason for restricting FAT32 to 32 GB, that should be added to the paragraph as well. Dpbsmith (talk) 16:37, 23 February 2006 (UTC)
Anyone know if it could also read/write standard PC disks? Plugwash 21:26, 25 February 2006 (UTC)
though some badly behaved tools managed to introduce it, anyone like to clarify? Plugwash 14:39, 12 June 2006 (UTC)
The FAT32 boot sector information was completely missing, as many have pointed out before but no one fixed.
So, since I'm currently writing software dealing with these structures, I've added the information as much as I was concerned with it. There's still some things missing, such as what the File System Information Sector is about, and what some other fields contain (Flags, Version, etc.). Yet, at least it should be easier to add such information now that the table has been separated into parts for FAT12/16 and FAT32.
Also, this discussion page is way too big. I've removed some parts that appear to be handled now by my changes or are old Q&As that do not need to be here any more.
Tempel 14:52, 12 June 2006 (UTC)
Are there any sources giving the definition of attribute bit 6 (0x40) as "device"? I haven't been able to find anything online; the Microsoft FAT32 spec simply says "reserved". (It certainly seems to have some meaning to Windows; editing a directory entry to set bit 0x40 leads to an "access denied" file in WinXP.) -- Jkew 22:16, 27 July 2006 (UTC)
The article says:
I fail to fully understand this complaint, since individual swap files are limited to 4GB anyway, even on NTFS.
I think this entire paragraph should be removed, since:
I have rewritten the paragraph to indicate that only a decreasing portion of the population is restricted by the FAT32 limits, which is, of course, true for any product (namely, consumer Windows) which is no longer on the market. -- Scott McNay 01:30, 30 July 2006 (UTC)
"Bad blocks: linked list" is wrong, surely -- there's no list of bad clusters, just a bad cluster mark in the FAT for each one. -- Jkew 19:23, 1 September 2006 (UTC)
This got me thinking - See Hierarchical_File_System. There the structure for bad blocks is said to be a B*-Tree, while here (for FAT) it's said to be a linked list.
I find both descriptions misleading. In particular, for HFS, the bad blocks, while being somehow ending up in a B-Tree, is not specific enough (I hope you'd agree that saying that the structure for bad blocks is a sequence of bytes is eventually correct as well, but not specific enough). In fact, the way to mark bad blocks in HFS+ is by making them property of a specific "bad blocks file" (how is it done in HFS Standard, I do not remember?). And I think that's what should be the description in the HFS and HFS+ pages, instead of the current unspecific "b-tree" statement.
On the same level, bad blocks on a FAT FS are marked as individual clusters, inside the allocation table (versus being marked as a specific file using a linked list).
Only that way the distinctiveness of the different ways to mark bad blocks on these file systems becomes clear.
Agreed? -- Tempel 08:16, 3 September 2006 (UTC)
The article says "The FAT32 formatting support in Windows 2000 and XP is limited to drives of 32 gigabytes", but surely it should be volumes of 32 GB, not drives? AnonMoos 01:26, 4 October 2006 (UTC)