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 B.
dsb@smart.net
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 B.
dsb@smart.net