other partition corrupted if (32GB) FAT32 filesystem filled >= 29GiB

  • Thread starter Thread starter Daniel B.
  • Start date Start date
D

Daniel B.

Is the following bug known (and is there a fix)?

On Windows 2000 with SP4, if I create 32GiB partition, format it as
a FAT32 file system, and try to fill it past a threshold that is
somewhere between 28.75 GiB and 29 GiB, Windows overwrites the
beginning of different partition (the C: volume) (writing over the
FATs and the root directory).

It seems that when Windows tries to write files beyond that point
in the partition, something in memory gets corrupted and it decides
to write over the C: partition.

The problem seems stable (not intermittent). (Testing by copying
1-GiB files to the 32GiB partition showed the threshold was between
28 and 29 GiB. Re-storing the C: partition and then re-testing
by copying 256-MiB files to the other partition was consistent in
revealing the threshold to be >28.75 GiB and <= 29 GiB.)



The earlier symptom I noticed was some files on a 32GB partition)
that appear corrupted from Windows but which are correct when I'm
booted in Linux and view the files (JPEG files).

Tracing through the FAT32 structures manually seems to reveal that
Linux is reading correctly (or at least the same way I'm
interpreting the FAT32 data).

I searched the raw partition for the first sector of the bad file
content reported by Windows, and found a match at an earlier
cluster and sector than where the file really started.

I checked several files that differed between Windows and Linux;
I think all the bogus data sectors were earlier than the correct
data sectors.

A number of correct locations were around cluster 2,000,000 and
sector 64,000,000, with bogus locations around cluster 1,600,000
and sector 52,000,000.


That is, Windows seems to be calculated the sector wrong, and
always with a lower value. (I don't know if it read the correct
cluster number from the directory entry and calculated the sector
number wrong from that, or if its calculations were erroneous
before that and it read something else as the cluster number.)



So, is anyone aware of this bug? Is there a fix? Any guesses as
to how reliably limiting my file system size to 28.75 GiB will
prevent corruption (especially catastrophic corruption of a
different partition's file system)?



Thanks,

Daniel
 
Daniel said:
So, is anyone aware of this bug? Is there a fix?
Click to expand...

Well, how big is the harddrive, and where on the drive is the fat
partition located?

I thinking about the 28bit lba vs 48bit lba issue. If this is not in
order, data corruption can/will occur if data is written beyond the
128GB boundary
 
jorgen said:
Well, how big is the harddrive, and where on the drive is the fat
partition located?

I thinking about the 28bit lba vs 48bit lba issue. If this is not in
order, data corruption can/will occur if data is written beyond the
128GB boundary
Click to expand...

So the maximum sector number that works should be 2^28 - 1? (And
2^28 = 2^8 * 2^20 = 256 * 1048576 = 268435456, right?)


It's a 250 GB (about 232 GiB) IDE/ATA disk (488379168 sectors).

The partition is from sector 202435128 to sector 269538569.

So yes, it looks like the partition goes past the 128GB limits.
(That's exactly 128.0 GiB, right?)

(And the C: partition that gets corrupted is right at the beginning
of the disk, right where writes would go if a sector number right
over the 29-bit threshold were stuffed into a 28-bit fields with
the high bits dropped.)


Is there any fix for Windows 2000?


Hey, something doesn't quite add up regarding where I start having
a problem:


269538569 - sector number of last sector in partition
-202435128 - sector number of first sector in partition
----------
67103441
+1
----------
67103442 - number of sectors in partition (and that's also the
FAT filesystem size per Linux's "file" command)


So after writing 29GiB, the highest written sector's number is at
least:


67103442 / 32 * 29 = 60812492 sectors of data

202525128 - starting sector
+60812492 - sectors for 29GiB
---------
263037660
-1
---------
263037659 - minimum sector number considering only data

263037659
+ 16375 - sectors in FAT 1
+ 16375 - sectors in FAT 2
---------
263070409 - minimum considering data and FATs (but
not root directory, and 32 reserved sectors)


Hmm. I expected that number to be a lot closer to 268435456.
It's still 5,000,000 sectors away.

Did I miscalculate something?

Would Windows likely be using higher sector numbers, leaving
lower-numbered ones unused? (This was all on a partition that I
reformatted before copying the 29GB to it.)

Thanks,
Daniel
 
Your Windows 2000 installation isn't properly configured to support
48-bit LBA:
You must enable the support in the Windows registry by adding or
changing the EnableBigLba registry value to 1 in the following
registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters
<http://support.microsoft.com/kb/305098>
 
Andy said:
Your Windows 2000 installation isn't properly configured to support
48-bit LBA:
You must enable the support in the Windows registry by adding or
changing the EnableBigLba registry value to 1 in the following
registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\atapi\Parameters
<http://support.microsoft.com/kb/305098>
Click to expand...

Just be sure to read the whole KB. Just editing the registry is the
dangerous part. It is very important that you have the updated driver.
 
Back
Top