Re: Windows 95 fdisk, format, SCSI hard drives, and moby lossage

Tech-Archive recommends: Fix windows errors by optimizing your registry

Norman Diamond wrote:
Microsoft has time to fix bugs, but only the ones that survive triage.
Some serious bugs get killed in triage. Others aren't allowed into
triage in the first place.

So Norman, what is your point here?
That MS has not considered this particular bug as serious?
Probably they were right, as it occurs only in very special
conditions - and you've discovered the root cause
only now, but were not able to present it to MS support before?
Yes, huge bugs keep stalking in stable released products... the world
isn't perfect.

--PA


"Alexander Grigoriev" <alegr@xxxxxxxxxxxxx> wrote in message
news:OyuHnnnFJHA.5448@xxxxxxxxxxxxxxxxxxxxxxx
Norman,
Microsoft doesn't have much time to fix things. They are always busy
making other bugs and misfeatures. You know, their bugfix process is
so heavy and overcomplicated, they would rather prefer not to do that.

"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message
news:eSL2jViFJHA.768@xxxxxxxxxxxxxxxxxxxxxxx
The subject is old news, but I finally analysed this bug a few months
ago
and it still seems outrageous that no fix was ever offered. This
report and
links are also posted on the web.
http://www.geocities.jp/hitotsubishi/w95_fdisk_format/

My first personally owned computer came with Windows 95 OSR2
preinstalled.
Shortly after buying it, I added peripherals which seemed appropriate
for
making backups: an external 3200MB SCSI hard disk drive, a PCMCIA-SCSI
adapter card to connect the PC to the disk, a cable, and a
terminator. At
this point, I had just finished buying equipment suitable for Windows
95 to
lose every file, but I didn't know it yet. Gradually I made backups
of some
files, made backups of some more files, made backups of some more
files, and
then saw that the backups of my most important files didn't exist any
more.

Over several months I visited the retail store several times where I had
bought the equipment, exchanged the PCMCIA-SCSI card for a different
maker's
card, tried a different hard drive (converting the store's new
merchandise
into used merchandise), visited the maker of the PC, visited the
maker of
the second PCMCIA-SCSI card and the first hard drive, experimented with
other PCs, experimented with other language versions of Windows 95,
experimented with the original retail upgrade release of Windows 95,
etc.
The results were always the same. I could write backups of some files
onto
the external hard drive, then write backups of other files, and the
first
set would turn into garbage. After several months and expenditures on
train
fares exceeding the value of Windows 95, I acquired enough experience to
reproduce the problem in 10 minutes, but no solution.

Microsoft's web site had two downloads which could fix bugs in the
way the
original release of Windows 95 handled internal IDE hard drives.
There were
no such fixes for OSR2, and no fixes at all for handling external
SCSI hard
drives.

Eventually I tried another experiment. The maker of the PCMCIA-SCSI
card had
provided drivers and utilities for Windows 95, Windows NT4, Windows
3.1, and
MS-DOS. I figured out how to install MS-DOS drivers in the CONFIG.SYS
and
AUTOEXEC.BAT files of Windows 95, and run the maker's utilities to
partition
the SCSI drive. After a reboot (equivalent to the reboot ordinarily
needed
after FDISK), Windows 95's format operation still worked. After that,
backups worked. Files did not get lost.

Since my personally owned copy of Windows 95 OSR2 was a preinstalled OEM
product, naturally Microsoft asserted that the PC maker was
responsible for
fixing bugs in Windows 95. Naturally the maker did not agree. I was
still
left with a garbage OS, wasted months, and wasted expenses, though
fortunately I had found a workaround.

Windows 98's FDISK command was different. It worked (for creation of
partitions and logical drives). Then Windows 98 SE came along and its
FDISK
command was broken differently, but when it worked, it wokred (for
creation
of partitions and logical drives). Microsoft announced a download to fix
Windows 98 SE's FDISK, but I couldn't get it, so I asked Microsoft. This
time Microsoft actually let me communicate with a support manager.
But the
support manager also refused to let me get the fix for Windows 98 SE's
FDISK. Microsoft's support manager further denied that Windows 95
operated
the way it did.

Windows NT4's disk manager seemed to work, and later Windows 2000's disk
manager seemed to work.

So anyway, for 11 years I was blaming Windows 95's FDISK command. As
well, I
blamed Microsoft's lack of testing, lack of appropriate process to
submit a
bug report, and false responses when I finally had the opportunity to
report
the bug.

Recently I had occasion to reproduce the problem again and see what
Windows
95 really did. The results were surprising. The same old repro case
operated
the same as always. But it turned out that FDISK was not 100% to blame.

The repro case uses the procedure recommended by Microsoft. In
Windows 95's
device manager, enable INT13 on the external hard drive. Reboot. Run
FDISK.
Reboot. Format the logical drives. Sometimes another reboot is necessary
before being able to write long filenames (an unrelated but documented
Windows 95 bug). The second and third logical drives appear to overlap.
Writing files to the third logical drive destroys the contents of the
second
logical drive. Running scandisk on either of them further destroys the
other. The first logical drive appears safe, but now I know that was
just an
accident.

This time I did further experiments. Run FDISK. Reboot to Windows
2000. Use
Windows 2000 to do the formatting. The result works! Or use Windows
2000 to
create the extended partition and create the logical drives but do not
format the logical drives, then reboot to Windows 95, and use Windows
95 to
do the formatting. The result works! So the problem is not only
Windows 95
FDISK. The problem is the combination of Windows 95 FDISK and Windows
95's
format utility.

Obviously Windows 95 is long gone and will never be fixed now. I
still blame
Microsoft's lack of testing, lack of appropriate process to submit a bug
report, and false responses when I finally had the opportunity to
report the
bug.

The repro case still repros the same as always. Here is a zip file
containing 110 screenshots. (So few because I was too lazy to capture
some
of the screenshots during Scandisk's operation.) After unzipping, the
filenames can be viewed in alphabetical order to view the sequence of
operations. I used funny spellings like "xplore" for some Windows
Explorer
screenshots, "zcandizk" for some Scandisk screenshots, and "zf'ddisk"
for
some FDISK screenshots, so that the results could be viewed in order.
http://www.geocities.jp/hitotsubishi/w95_fdisk_format/fdisk_format_screenshots.zip


The hard drive's maker designated it 3200MB in base 10. Windows 95
detected
it as 3066MB in binary which is fine with me. The extended partition is
3065MB which is also fine with me (the loss of 1MB of unused space is
really
pretty trivial in comparison to the loss of gigabytes of files). The
logical
drives are 1022MB, 1022MB, and 1021MB. I selected logical drive sizes
just
under 1GB so that cluster sizes would be 16KB instead of 32KB.

After these recent experiments, I also figured out what the
combination of
Windows 95 FDISK command and format utility had really done, in order to
create the overlapping logical drives. Windows 95 decided that the
SCSI hard
disk had 32 sectors per track, 64 tracks per cylinder (64 heads), and
3066
cylinders (3066MB), which is fine with me. The physical drive has
6281856
sectors but Windows 95 used only 6279168 of them, which is fine with
me (the
loss of 1MB of unused space is really pretty trivial in comparison to
the
loss of gigabytes of files). The EBR chain is correct, LBA sector
numbers
2048, 2095104, and 4188160. The PBR for the first logical drive is
correctly
located at LBA 2080, and its FAT and data area are correctly offset from
there. The PBR for the second logical drive is correctly located at LBA
2095136, and its FAT and data area are correctly offset from there.
The PBR
for the third logical drive is located at LBA 2091040, inside the first
logical drive, near the end of the first logical drive. The third
logical
drive's FAT and data area are correctly offset from its mislocated
PBR, so
only a little bit of them overlap with the first logical drive and
most of
them overlap with the second logical drive. This certainly explains
why the
destruction I had seen came from the overlap between the second and
third
logical drives.

An image of the entire hard disk drive, after FDISK and format but
before
copying any files, can be downloaded from the following link. The zip
file
is only 3MB but be reminded that the unzipped file will require 3GB.
http://www.geocities.jp/hitotsubishi/w95_fdisk_format/3200_hdd.zip

I still wonder how any programmer can care so little about the
reliability
of their product. I still wonder how any vendor of a program can
dedicate
huge resources to toying with cosmetic issues but ignore and tell
lies about
moby lossages like this. Vendors of hard drives were sued for
problems less
serious than this. Vendors of floppy drives were sued for billions of
dollars for potential problems which might case 1/1000 of this amount of
data loss but had never been reported as actually causing a data
loss. This
software bug is 100% reproducible and was delivered to every customer of
Windows 95, so I cannot quite imagine how I was the only victim who ever
detected it.



.

Relevant Pages

  • Re: Windows 95 fdisk, format, SCSI hard drives, and moby lossage
    ... That MS has not considered this particular bug as serious? ... Was it a very special condition to buy a computer with Windows 95 ... Was it a very special condition to use Windows 95 FDISK and Format? ... of partitions and logical drives). ...
    (microsoft.public.development.device.drivers)
  • Re: Windows 95 fdisk, format, SCSI hard drives, and moby lossage
    ... That MS has not considered this particular bug as serious? ... Was it a very special condition to buy a computer with Windows 95 preinstalled and included in the cost of the computer? ... Well as mentioned I thought I discovered the root cause 11 years ago because if I used any partitioner other than Windows 95 FDISK then I didn't have this problem. ... of partitions and logical drives). ...
    (microsoft.public.development.device.drivers)
  • Re: Windows 95 fdisk, format, SCSI hard drives, and moby lossage
    ... My first personally owned computer came with Windows 95 OSR2 preinstalled. ... Windows 98's FDISK command was different. ... of partitions and logical drives). ... bug report, and false responses when I finally had the opportunity to ...
    (microsoft.public.development.device.drivers)
  • Re: Windows 95 fdisk, format, SCSI hard drives, and moby lossage
    ... My first personally owned computer came with Windows 95 OSR2 preinstalled. ... Windows 98's FDISK command was different. ... of partitions and logical drives). ... bug report, and false responses when I finally had the opportunity to report ...
    (microsoft.public.development.device.drivers)
  • Windows 95 fdisk, format, SCSI hard drives, and moby lossage
    ... but I finally analysed this bug a few months ago ... My first personally owned computer came with Windows 95 OSR2 preinstalled. ... Windows 98's FDISK command was different. ... of partitions and logical drives). ...
    (microsoft.public.development.device.drivers)