Vista Explorer Bug?

[Guest]

Open windows explorer.
Make sure to have the folders on the left and file list on the right.
Click a folder such as 'Documents'
Put your mouse cursor over the right pane and click and drag over a few
files (usually put the mouse cursor just past the end of the filename then
drag to the left).
Hit the delete key.
My computer says 'Do you want to move this folder to the Recycle Bin' and
the folder says 'Documents'.
This shouldn't be, I almost deleted my entire documents folder.
If you click in the white space on the right once first, then click again
and drag to select files, it works ok.
Is this something just with my system or a bug?
If a bug, glad to report this. Potentially a big bug if someone doesn't
realize and deletes the whole folder.

 

[Marcin Domaslawski]

Hi,

I know what do you mean - it is that functionality. Notice that first you
set focus on folder's tree. When you just mark and drag file on right side,
selected item (folder) on left side doesn't loose focus - all time is
selected and highligthed. But when you click on right side focus is chaged.
The same thing you can notice in Windows XP.

Marcin Domaslawski

 

[Lucvdv]

Hi,

I know what do you mean - it is that functionality. Notice that first you
set focus on folder's tree. When you just mark and drag file on right side,
selected item (folder) on left side doesn't loose focus - all time is
selected and highligthed. But when you click on right side focus is chaged.
The same thing you can notice in Windows XP.

No, the same thing can not be seen in XP.

Selecting files by dragging the mouse around them DOES change the focus to
the file list in XP, as it should be and has always been before Vista.


What the OP just described is only one of three different explorer bugs I
ran into in the first week after installing Vista.

It's incomprehensible that _elementary_ bugs like this would get through
beta tests unnoticed, so it didn't come as a surprise to me when they
admitted to be working on SP1 already BEFORE consumers could buy Vista.



The second one (that I ran into) is just as bad, and also keyboard-related:
right-click in the file pane in a folder that already contains many
files/subfolders, and select "New" --> "Folder". Release the mouse and
*immediately* start typing the name, without waiting for visual feedback of
the "New folder" folder appearing in the list. If you do that in Vista,
explorer will sometimes rename an existing file or folder, instead of the
new one it's creating.

You don't have to have a slow system to get bitten by this one: I've had it
happen to me several times on a Pentium D 2.8 GHz with 2 GB of RAM, with no
other applications running.




Number three is the worst of the three IMO, but it won't happen very often,
except for people who use WinRAR and sometimes expand multipart RAR files
by right-clicking on them and selecting "extract here".

Suppose you have 20 files in a folder. Select one in the middle, say the
10th.

Now, before continuing in explorer, use another application to create a
subfolder in that folder. Because it's a subfolder, explorer will display
it at the start of the list, _before_ the selected file (it will probably
work with new files just as well, as long as explorer shows them before the
selected file).

Now, back in explorer, Shift-Click a file near the end to select a number
of files.

Where does the selection range now begin? Not at the file that was
initially selected, but as many places *before* that as new files/folders
were added.


An example will make it clearer:

Files exist, click File5:
File1
File2
File3
File4
File5 << highlighted.
File6
File7
File8

A folder is added by another app, explorer auto-updates its display:

Folder
File1
File2
File3
File4
File5 << highlighted.
File6
File7
File8

Now shift-click on File6. Result:

Folder
File1
File2
File3
File4 << highlighted.
File5 << highlighted.
File6 << highlighted.
File7
File8

When File5 was selected, it was at the 5th position in the list.
When you Shift-click on File6, it selects everything from the 5th position
up to the current position of File6.

If you don't notice it (for example because the start of the selected range
has scrolled out of view) and hit "delete", you lose one or more files you
didn't intend to detele.

How I ran into it with multi-part rar archives: right-click on first part,
select "extract here" (it extracts all parts), shift-click on last part,
"delete". Bye bye data.



Each of the three bugs above (including the OP's) has cost me data within
the first week after installing Vista (or would have cost me, if it weren't
for backups and recycle bin), so please don't come and tell me that none of
them was reported during the beta period.

 

[Marcin Domaslawski]

Hello,

No, the same thing can not be seen in XP.

Selecting files by dragging the mouse around them DOES change the focus to
the file list in XP, as it should be and has always been before Vista.

Set view on icons, mark files, select folder on the tree, drag and drop
files on the end and press delete ... same issue.

The second one (that I ran into) is just as bad, and also
keyboard-related:
right-click in the file pane in a folder that already contains many
files/subfolders, and select "New" --> "Folder". Release the mouse and
*immediately* start typing the name, without waiting for visual feedback
of
the "New folder" folder appearing in the list. If you do that in Vista,
explorer will sometimes rename an existing file or folder, instead of the
new one it's creating.

I'm not able to repeat it.

Number three is the worst of the three IMO, but it won't happen very
often,
except for people who use WinRAR and sometimes expand multipart RAR files
by right-clicking on them and selecting "extract here".
.....

How I ran into it with multi-part rar archives: right-click on first part,
select "extract here" (it extracts all parts), shift-click on last part,
"delete". Bye bye data.

Right it works ... I mean is as you said


Marcin Domaslawski

 

[Lucvdv]

I'm not able to repeat it.

It only happened occasionally here too, but it did happen, and more
than once or twice.

Speed of the drive where you're doing it will probably play a part,
and I'm not certain, but maybe I only have had it on USB and NAS
drives (I use those a lot, more than local storage).

 

[cquirke (MVP Windows shell/user)]

No, the same thing can not be seen in XP.

Selecting files by dragging the mouse around them DOES change the focus to
the file list in XP, as it should be and has always been before Vista.

Yes, I'd say that's a bug, and worth reporting. I'm not in front of
Vista right now, but I intend to test this.

What the OP just described is only one of three different explorer bugs I
ran into in the first week after installing Vista.

It's incomprehensible that _elementary_ bugs like this would get through
beta tests unnoticed, so it didn't come as a surprise to me when they
admitted to be working on SP1 already BEFORE consumers could buy Vista.

Leading up to RTM, issues have to be sorted into "fix before RTM",
"fix after RTM" and "won't fix". Everything that is sorted into the
second category, may be rolled into an SP1.

Beta testing is not production use. I am finding different issues now
that I am setting up Vista for real-world use than I found when I was
beta testing it, and this is not just because I'm now running the
changed RTM code base. The way I use it is different.

The second one (that I ran into) is just as bad, and also keyboard-related:
right-click in the file pane in a folder that already contains many
files/subfolders, and select "New" --> "Folder". Release the mouse and
*immediately* start typing the name, without waiting for visual feedback of
the "New folder" folder appearing in the list. If you do that in Vista,
explorer will sometimes rename an existing file or folder, instead of the
new one it's creating.

That bug is part of a class of UI race conditions that arise when
input events are queued out of synch with each other (e.g.
mis-serializxation of mouse vs. keyboard) or other event cues (e.g.
those that pop up dialogs or transfer keyboard focus).

There are some golden rules here:
- never locate a control with different meaning in the same place
- test on slow PCs to boost latency and provoke race conditions
- consider the impact of show-stoppers (suspend, UAC prompts)
- consider the impact of wrappers (e.g. remote desktop, virt)

For an example of the first rule, consider a dialog with a single
button that starts off as "OK" while the control inits, but changes to
"Cancel" once the process starts. If you click when the button shows
as OK, but the click is processed after the button changes to
"Cancel", then you have a primary UI failure.

You don't have to have a slow system to get bitten by this one: I've had it
happen to me several times on a Pentium D 2.8 GHz with 2 GB of RAM, with no
other applications running.

Various things can make fast systems run slowly, such as additional
overhead or slower access (e.g. when logic designed for folders on
local HDs is applied to mapped drive letters over slow connections, or
wonky diskettes that stall on failing sectors).

Number three is the worst of the three IMO, but it won't happen very often,
except for people who use WinRAR and sometimes expand multipart RAR files
by right-clicking on them and selecting "extract here".

Suppose you have 20 files in a folder. Select one in the middle, say the
10th.

Now, before continuing in explorer, use another application to create a
subfolder in that folder. Because it's a subfolder, explorer will display
it at the start of the list, _before_ the selected file (it will probably
work with new files just as well, as long as explorer shows them before the
selected file).

Now, back in explorer, Shift-Click a file near the end to select a number
of files.

Where does the selection range now begin? Not at the file that was
initially selected, but as many places *before* that as new files/folders
were added.

This is similar to a bug in Nero Express 6. If you select items in a
layout and drag them into a folder within the layout, the wrong items
are moved - because they are selected by the order that applied before
the move starts, and the selection order is applied to select them as
the operation proceeds.

So if the first item is moved into a folder at the top of the list,
the ordering of all items below is shifted up; what was (say) the 4th
in the list is now the 3rd. Now the second item is selected, but what
was the 4th in the list then, is now a different item - and it is this
different item that gets moved. And so it goes on, and gets worse.

Unless WinRAR behaves differently in Vsita than it does in XP, this
would be a WinRAR bug, not a Windows bug.


Some more Vista UI bugs:

If a folder operation is interrupted by a UAC pop-up, the focus
returns to a different selectable item within the Windows Explorer
after the UAC prompt is dismissed.


If you use the System dialog box that shows the PC's performance
indication, and go into the details, then the mouse will no longer
click things. You can clear this state:
- press Ctl+Alt+Del
- click the Cancel on the full-screen dialog (nil happens)
- click the Cancel again (now it clicks OK)
- now the mouse will show links clickable, and click works

This needs repro; I saw this repeatedly, but have only tested it on
one PC with one particular PS/2 mouse. No 3rd-party drivers, no mouse
issues in other contexts or when mouse used on other PCs.


Here's a bug-like effect of the way UAC works:

If a folder operation is interrupted by a UAC prompt and the UAC
prompt is cancelled, the UI feedback of the operation does not
indicate the operation was cancelled. For example, if you attempt to
delete a file in "C:\Program Files" and decline permission at the UAC
prompt, the operation status is "OK" even tho the item is still there.


Here's a nasty XP UI race condition:

Highlight a file in XP Windows Explorer that you know you want to
delete. Press Shift+Del to delete directly rather than to Recycled,
then press Enter to OK the confirmation dialog. The item is deleted -
but often it is also "opened". The malware risks should be obvious.

An example will make it clearer:

Files exist, click File5:
File1
File2
File3
File4
File5 << highlighted.
File6
File7
File8

A folder is added by another app, explorer auto-updates its display:

Folder
File1
File2
File3
File4
File5 << highlighted.
File6
File7
File8

Now shift-click on File6. Result:

Folder
File1
File2
File3
File4 << highlighted.
File5 << highlighted.
File6 << highlighted.
File7
File8

When File5 was selected, it was at the 5th position in the list.
When you Shift-click on File6, it selects everything from the 5th position
up to the current position of File6.

That's similar to the Nero Express 6 bug. In the case of Nero Express
6, the workaround is to select, cut, paste rather than drag and drop,
so that the selection process is properly serialized.

Each of the three bugs above (including the OP's) has cost me data within
the first week after installing Vista (or would have cost me, if it weren't
for backups and recycle bin), so please don't come and tell me that none of
them was reported during the beta period.

Here's a far more serious and insideous MS bug:

Use one of Microsoft's new wireless keyboards that:
- has no status LEDs on the keyboard
- has these LEDs on the sensor, typically tucked away out of sight
- has a new "Function" mode for Fn keys
- duuuuhfaults to this new mode on startup

The new "Function" mode maps different actions to the function keys.

This is *really* ugly, because what would normally be "Rename" or
"Edit field" for the F2 key now becomes "Undo".

So you're in Windows Explorer, and you've done a few file operations;
moved files from here to there, etc. You press F2 to rename a file,
and nothing happens, so you press it again again again again, then
shrug and rt-click, Rename. Meanwhile a whole bunch of previous file
operations are undone, with no visual cue that this has happened.

You then delete some files on the assumption that they are already
copied somewhere else - but they aren't, because that operation was
silently undone, thanks to the new "Function" key mapping.


If that doesn't spook you, try this:

You're in Excel, entering financial data. You've added rows to some
sections and changed formulas to sum the extra rows, and now you go
back to correct a data entry mistake.

You press F2 to edit the cell, and nothing happens. You press it
again again again again, then shrug and rt-click, Edit, and off you
go. Meanwhile, a number of previous edits are silently rolled back,
significantly breaking the accuracy of your spreadsheet in ways that
even a careful check on input data mau miss.

Same thing applies to data entry in Access, etc.

It takes rare skills to make a keyboard become a safety risk. IMO,
the standard layout of keys, and what they do, should NOT be stuffed
around with to "improve" things... I consider these MS keyboards to be
unfit for use, just as I'd judge bad RAM or a failing HD.

--------------- ---- --- -- - - - -

Saws are too hard to use.
Be easier to use!

 

[Guest]

Another issue:

For some time now I haven't been able to select multiple files in explorer.
I can not drag and select, no matter what view I am using, not use CTRL + A,
select all in menu is greyed out etc. I can select files in "open
file"-dialogs or when launching Documents, or Music, or the other shortcuts
(not Computer) from start-menu. However, if I select any other folder not a
subfolder of these (eg, Documents) I lose the ability to select multiple
files again. The weird thing is that it's sometimes working for all, but
thats rare.

Time to reinstall Vista for my part (for mostly other reasons), I just hope
I don't stumble upon it again.

 

[Lucvdv]

Unless WinRAR behaves differently in Vsita than it does in XP, this
would be a WinRAR bug, not a Windows bug.

It's an explorer bug. I only mentioned winRar because that's what I
was using when I first encountered it, but it works with a command
prompt or with powershell just as well (I just tried both to be sure).


Create/open an empty test folder in explorer, open a CMD window, and
'cd' to the same folder.

Now first run this at the command prompt to create some files:

C:\Test>for /L %i in (1,1,10) do echo Hello > %i.txt

Now click on "5.txt" in the explorer window to select it.
Next, run this at the command prompt to add some directories:

C:\Test>for /L %i in (1,1,3) do md dir%i

You'll see the new folders appear at the start of the file list in
explorer. File 5.txt remains selected.

Now shift-click "6.txt" and see what happens.



It works just as well with Powershell, with these commands:

C:\Test> 1..10 | foreach { echo x > $_".txt" }
[select file in explorer]
C:\Test> 1..3 | foreach { md dir$_ }
[shift-select other file]


My opinion is that this makes it simply unsafe to use Vista's file
explorer while any other application is running that could add files
to the same folder (as I said before, if the folder contains many
files, the error may occur off-screen).

 

[Andrew]

Hi.
I recently purchased a laptop with Vista installed. A day later I boot up and windows explorer just gives a dialogue box say something along the lines of "problem with windows explorer, trying to rectify problem". Another box then opens and says "windows explorer restarting". This goes on in a loop for hours, or until I switch the machine off. I was told i need to reinstall vista from scratch, but doing so would loose all my files. Has anyone had this problem or knows what would be causing it?

EggHeadCafe.com - .NET Developer Portal of Choice
http://www.eggheadcafe.com

 

[cquirke (MVP Windows shell/user)]

cquirke (MVP Windows shell/user) wrote:

It's an explorer bug. I only mentioned winRar because that's what I
was using when I first encountered it, but it works with a command
prompt or with powershell just as well (I just tried both to be sure).

Let's keep it as simple and general as possible, so we don't end up
chasing WinRAR, PowerShell (is that what used to be Monad?) etc.

Create/open an empty test folder in explorer, open a CMD window, and
'cd' to the same folder.

OK, in XP and Vista32

Now first run this at the command prompt to create some files:

C:\Test>for /L %i in (1,1,10) do echo Hello > %i.txt
OK

Now click on "5.txt" in the explorer window to select it.
OK

Next, run this at the command prompt to add some directories:

C:\Test>for /L %i in (1,1,3) do md dir%i

You'll see the new folders appear at the start of the file list in
explorer. File 5.txt remains selected.

In XP, dirs appear at the bottom, because re-sort only happens after a
refresh (which is useful)

In Vista, dirs also appear at the bottom, which isn't what I expected
in the light of your bug description; I was half-expecting to see them
appear at the top (i.e. sorted into place) and then have the selection
mis-ordered with the wrong selection in next step.

Now shift-click "6.txt" and see what happens.

In XP, 5.txt and 6.txt are highlighted

In Vista, 5.txt and 6.txt are highlighted

My opinion is that this makes it simply unsafe to use Vista's file
explorer while any other application is running that could add files
to the same folder (as I said before, if the folder contains many
files, the error may occur off-screen).

I'm not seeing a bug.

Does it matter what View I'm using? I always use List View, rather
than the dummy icon views, and that may change the sorting, ordering
and so on. Let me re-test in Vista32 in an Icon View... no, it's
still looking OK here. Let's see your earlier desc... yes, that was
the bug I expected to see (the same as the one I see in Nero Express
6), but I don't get repro here.

I tested in an arbitrary location on a FAT32 volume. Does it have to
be NTFS, and/or one of the shell folders?

I wonder if some shell integration is affecting the way Windows
Explorer refreshes? I ask, because I'm not seeing the folders head
the list until F5 (refresh), which also clears the selection so that
there's no invalidation effect.

Try repeating the experiment in Safe Mode.

If that breaks repro, use Nirsoft's Shell Extension Viewer (or if
Vista has that management capability, use that) to suppress 3rd-party
shell integrations such as WinRAR, WinZip etc. and retry.

If that also breaks repro, then test-to-break by adding back the
3rd-party shell extensions one at a time.

I used the above to pin down why XP didn't show the size of a .ZIP
file in the Status bar when it was highlighted; it wasn't ZipFldr.dll
as I half-expected, but a WinZip 8.1 shell integration component.


These are good (as in, worth finding!) bugs, so let's try to pin 'em
down. Can we get a witness, y'all? Join the repro party?

--------------- ---- --- -- - - - -

Saws are too hard to use.
Be easier to use!

 

[Lucvdv]

In XP, dirs appear at the bottom, because re-sort only happens after a
refresh (which is useful)

In Vista, dirs also appear at the bottom, which isn't what I expected
in the light of your bug description; I was half-expecting to see them
appear at the top (i.e. sorted into place) and then have the selection
mis-ordered with the wrong selection in next step.

?? Vista immediately sorts them here, putting them at the top.

When I create a new folder in explorer, it even jumps around while I'm
still entering its name (initially placed at 'N', jumps to new
alphabetical order while typing).

In XP, 5.txt and 6.txt are highlighted

In Vista, 5.txt and 6.txt are highlighted

Here: 2, 3, 4, 5 and 6 were selected.


It must be a setting somewhere, but I can't imagine which one that I
changed could influence this.

What I changed is the same that I used to change in XP and win2k: show
hidden, show extensions, list view, and make list view the default for
all folders. All the rest is still at default, AFAIK.

 

[Lucvdv]

I tested in an arbitrary location on a FAT32 volume. Does it have to
be NTFS, and/or one of the shell folders?

I think you caught it there. It only does it on NTFS (I haven't used
any FAT disks ever since NT4, even reformat USB disks before using
them, but luckily I remembered having a FAT formatted CompactFlash in
my PPC and an adapter to plug into my PC for the test

Safe mode didn't change anything, it still did it.

I tested in a plain directory straight below the root on my C drive,
and the same on the CF.

 

[cquirke (MVP Windows shell/user)]

cquirke (MVP Windows shell/user) wrote:

?? Vista immediately sorts them here, putting them at the top.

So now the Q is: What's different about your system, that it does this
whereas mine doesn't, or vice versa?

When I create a new folder in explorer, it even jumps around while I'm
still entering its name (initially placed at 'N', jumps to new
alphabetical order while typing).

Definitely hasn't been my mileage.

Here: 2, 3, 4, 5 and 6 were selected.

Yup, that flows from the earlier mileage divergence.

It must be a setting somewhere, but I can't imagine which one that I
changed could influence this.

There was an ancient Win3.yuk-era setting in System.ini or Win.ini
that was whether File Manager should refresh itself or not. Maybe
that persists as a registry setting in Vista... but my guess is that
it's a side-effect of some 3rd-party integration.

What I changed is the same that I used to change in XP and win2k: show
hidden, show extensions, list view, and make list view the default for
all folders. All the rest is still at default, AFAIK.

GMTA - that's what I always change, too, so that's not it.

What's your mileage in Safe Mode?

--------------- ---- --- -- - - - -

Saws are too hard to use.
Be easier to use!

 

[cquirke (MVP Windows shell/user)]

cquirke (MVP Windows shell/user) wrote:

I think you caught it there. It only does it on NTFS (I haven't used
any FAT disks ever since NT4, even reformat USB disks before using
them, but luckily I remembered having a FAT formatted CompactFlash in
my PPC and an adapter to plug into my PC for the test

Safe mode didn't change anything, it still did it.

OK, so far it looks like a Vista bug, possibly connected to NTFS
metadata handling, or perhaps a consequence of NTFS's ordered
directory index. Maybe it's delayed in FATxx only in deference to the
slower linear directory access that NTFS avoids.

Try turning off auto-thumbnails, maybe that will affect it - I don't
turn that off on my systems (yet).

I tested in a plain directory straight below the root on my C drive,
and the same on the CF.

And the CF is FATxx? Then it's back to wondering about 3rd-partyware,
though if Safe is also affected, that suggests it isn't as simple as a
startup item. Persistent handlers operating as CLSID in HKCR may well
operate in Safe Mode as well, though.

--------------- ----- ---- --- -- - - -

Error Messages Are Your Friends

 

[Lucvdv]

And the CF is FATxx? Then it's back to wondering about 3rd-partyware,
though if Safe is also affected, that suggests it isn't as simple as a
startup item. Persistent handlers operating as CLSID in HKCR may well
operate in Safe Mode as well, though.

The CF is FAT24 (often referred to as FAT16, but there exists no such thing
as FAT16 for disks > 32MB

But I think you misunderstood "the same": the problem doesn't occur on the
CF. What I meant is that I tested "at the same kind of location" on the
CF, a plain directory straight under the root.


I think it's time to wait for someone to check if Explorer/NTFS does it on
his machine too. I only have one Vista machine right now, and I don't
expect more to be added soon.

 

[cquirke (MVP Windows shell/user)]

The CF is FAT24 (often referred to as FAT16, but there exists no such thing
as FAT16 for disks > 32MB

No, that's just as much FAT16 as ever (16-bit cluster addresses in
FAT) even if the partition and volume typbe bytes had to change to
overcome limitations from the eras of MS-DOS versions up to 5.

"Non-square" bitfields such as FAT12, 24-bit color etc. aren't
machine-efficient and generally get rounded up as capacity improves.
So when FAT16 got reworked, they went straight to 32-bit, at a time
that display color processing was already moving from 24-bit to 32-bit
even though no additional color info was stored in the extra 8 bits.

OTOH, "16-bit code" actually effectively uses 20-bit addressing via
the wonder of segment addressing. Even at its most restrictive,
DOS-era addressing will effectively use segment registers to page in
different 16-bit address spaces, which can overlap.

That may look really ineligant now, but the usual approach in the
16-bit home computer era was to have physically discrete 16-bit spaces
that had to be paged in via a "special" mechanism that was often not
transparent to software - either multiple ROM pages + display +
program RAM, or similar with 2 or more slabs of program RAM.

The moral from all this is: Build it big enough to last, even if the
initial response is horror at how slow it is and how much capacity
systems have to have to run it at all. That's why I don't criticise
Vista for being RAM-hungry and slower, etc.

But I think you misunderstood "the same": the problem doesn't occur on the
CF. What I meant is that I tested "at the same kind of location" on the
CF, a plain directory straight under the root.

OK, then we're back on track (though by now, I'd have to re-read to
remember what track that may have been) <g>

--------------- ---- --- -- - - - -

Saws are too hard to use.
Be easier to use!

 

[Lucvdv]

No, that's just as much FAT16 as ever (16-bit cluster addresses in
FAT) even if the partition and volume typbe bytes had to change to
overcome limitations from the eras of MS-DOS versions up to 5.

Yes, you're right of course. I don't know what I'd been drinking when
I wrote that.

12-bit was used initially, not because floppies were small enough as
they were, but because it allowed the boot sector, root directory and
FAT to reside on a single floppy track, eliminating head stepping
while reading/writing it. This was also the reason for the limited
and fixed number of entries in the root directory. And it brought
along the 'track 0 bad, disk unusable' message if a single sector on
the first track went bad.

The disk size was stored as a 16-bit number of sectors in FAT12, and
that's where the 32MB limit was.

 

[cquirke (MVP Windows shell/user)]

12-bit was used initially, not because floppies were small enough as
they were, but because it allowed the boot sector, root directory and
FAT to reside on a single floppy track, eliminating head stepping
while reading/writing it. This was also the reason for the limited
and fixed number of entries in the root directory. And it brought
along the 'track 0 bad, disk unusable' message if a single sector on
the first track went bad.

My first disk interface was a custon diskette interface for the ZX
Spectrum, which supported 40- and 80-track drives, single and double
sided, using 5 x 1024-byte sectors per track.

The first track wasn't used other than as a "parking" track, then the
first sector was file system chaining data and a few flags, then the
one after that was "the directory", holding 42 10-character file
names. One could manually reserve and use another 3 sectors (or more,
if you didn't mind head clicks) for alternate directories, poking a
value in the first sector to select each.

The disk size was stored as a 16-bit number of sectors in FAT12, and
that's where the 32MB limit was.

Ah! I seem to remember MS-DOS 3.3 allowing > 32M volumes in extended
partition, but no > 32M primary until MS-DOS 5

--------------- ---- --- -- - - - -

Saws are too hard to use.
Be easier to use!

 

[Lucvdv]

My first disk interface was a custon diskette interface for the ZX
Spectrum, which supported 40- and 80-track drives, single and double
sided, using 5 x 1024-byte sectors per track.

The first floppies I ever worked with were those giant 8" ones, on a
Digital PDP11.


The first computer I really owned was a TRS-80 model I (computer inside the
keyboard), with an 'expansion interface' (as large as the computer itself)
that allowed you to connect a printer and up to 4 floppy drives.

I had 4 drives of 160K each, but ISTR the original first drive models Radio
Shack sold stored only 90-something K per 5 1/4" 36-track disk (which
doesn't sound much, but it was twice the machine's RAM capacity

Those drives cost something like $500 a piece when Radio Shack started
selling them. I bought mine (and the computer) used, from a company that
was replacing all its model I's by brand new model III's (the same computer
in fact, just all in one case instead of interconnected ones with separate
power supplies, and with its Z80 clocked at 2 MHz instead of 1.77).


I remember us drilling extra holes in the floppy sleeves to turn them into
'flippies', disks you could turn over to use the other side. Disks were
being sold in single- and double sided variety, but in reality there was
only one manufacturing process for the two. 'Sidedness' was tested instead
of built into, and in later years most SS disks worked fine on both sides.


I was on my first job then. A student with his own computer was something
virtually unheard of back in the 1970's, at least here in Europe. We had
to measure our status by comparing pocket calculators instead.