Explorer weirdness

I have a whole shopping list here of Windows Explorer oddities. All of
these, unless otherwise noted, have happened under Win98, W98 SP1,
WinME, WinXP home, WinXP home SP1, WinXP home SP2, and WinXP Media
Centre Edition SP2 with a variety of software (including possible shell
extensions) installed or not (such as Corel suite applications, various
versions, and WinRar, or even WinZip on older Windows). Given that no
one such application/shell extension needs to be present, I conclude
that the oddities in question are not the result of third-party code,
but rather, are "features" of Explorer itself.

Hardware has varied, too -- a K6-2 400MHz with no 3d acceleration or
with a Voodoo 2; an Athlon XP 2000+ 32-bit single core with a GeForce2;
an Athlon XP 3800+ 64-bit dual core with an ATI Radeon Xpress 200; and
an Athlon XP 3800+ 64-bit dual core with an nVidia GeForce 6800GS.
Network has varied -- none, dial-up, or cable, with two different
network cards; empty network neighborhood. Sound hardware, irrelevant
as it seems, has varied.

Indexing service may be enabled or disabled on XP systems without
affecting these.

The only common denominators are the presence of an AMD CPU and lack of
a LAN, and I doubt that these're significant.

All oddities listed have been observed even after a recent reboot, with
low commit charge (a fraction of the 1GB physical RAM these machines
all had) and lots of free disk space, while browsing the local primary
partition (with the windows directory on it) without much else running
(and whatever else has varied, with nothing consistently present aside
from Windows itself).

None of the ones listed have been fixed by any one of years of
Microsoft patches to the various operating systems in question, or even
by the service packs, or even by migrating 98->Me->XP home->XP Media
Centre over donkey's years. As far as I can tell, all of them are
bugs/warts/misfeatures that Microsoft must surely by now know about and
is refusing ever to fix.

Any suggestions on workarounds, fixes, etc. are welcome, as every one
of these has seriously annoyed me at least once and mildly annoyed me
at least a trillion times.

(Any suggestions that don't mention either of the words "Mac" and
"Linux", that is.)

* An oddity occurs sometimes when doing any of the following:
- Changing directory in an open Explorer window
- Closing an open Explorer window
It occurs consistently the first time such an action is performed
after reboot and randomly
thereafter at infrequent intervals. Use of thumbnail views or the
Picture/Fax previewer seems
to increase the frequency; heavy use especially so.
Symptoms: Explorer becomes sluggish to respond to user input for a
while, during which
time all open Explorer windows spontaneously refresh. Selection state
is lost, and all
windows scroll spontaneously to the left/top. The annoyance this may
cause should be
obvious.
* Explorer leaks memory, slowly bloating to upwards of 250MB. On one
occasion it achieved
700, and on another over 1GB! Process size measured with Task
Manager, VM size
column. Use of thumbnail views and Picture/Fax previewer again seems
to worsen this
in proportion to the amount of such use.
* When rapidly renaming files, odd extraneous keyboard inputs are
processed that the user
did not type, principally, arrow and enter keypresses; more
generally, renaming files
sometimes behaves oddly. All of the following have been observed:
- Finish renaming, hit enter, hit down, selection moves down and to
the left, or down and to
the right, as if another arrow key were also hit. Also related
oddities.
- Finish renaming and the filename changes back spontaneously after a
few seconds,
especially if the only change was capitalization.
- Select several files to move, drag them to another folder (window
or in tree pane at left),
get "replace?" prompt and answer no, ending up with a single file
in the original folder,
which is selected. Hit F2 and the wrong file (i.e. not the selected
file) opens for renaming.
This one can be consistently reproduced: create folders A and B
with files named a.txt in
A and a.txt, b.txt, and c.txt in B. In the latter, select the first
two and drag to A. Answer
no when asked whether to overwrite A's a.txt. You should be left in
B with a.txt (selected)
and c.txt. Hit F2 and you're renaming c.txt.
- Renaming a file shortly after Shareaza 2.2.1.0 has downloaded it,
shortly after having
moved it within the library with same running, or shortly after
having renamed it under the
same circumstances (e.g. to correct a typo made in the first
rename) fails sometimes with
an alert that the file is "in use" and the edit you made is lost.
Annoying due to data loss
and surprise/inconsistent behavior factor. Moving behaves
similarly. May be a Shareaza
bug.
- When renaming files, the left pane may spontaneously change to
Search from Folder
Tasks or Folder Tree.
- (Windows XP only) When renaming files, the "Help and Support
Center" window
sometimes spontaneously opens and may steal the focus if it does.
Before this occurs,
Explorer suddenly becomes sluggish and there's additional disk
activity and the mouse
pointer flickers. When it happens, a popup does steal the focus as
the firewall reports that
Help and Support Center is trying to phone home. This occurs on a
system without any
spyware that Lavasoft Ad-Aware or Spybot Search and Destroy can
detect, but it is
spywareish behavior (windows opening spontaneously, suspicious
network activity).
- Renaming a directory while it is being viewed (using the tree view)
causes it to
spontaneously change its view and other settings, e.g. from
thumbnails to tiles.
* Moving files:
- Moving a file within the library of Shareaza 2.2.1.0 while this
application is running
sometimes fails complaining the file is "in use". Not consistent.
See above.
- Moved files sometimes disappear from the folder of origin but fail
to appear in the
destination folder for a significant amount of time, before
eventually showing up.
- (Possibly related) Moved files sometimes fail to disappear from the
folder of origin.
Thinking the move somehow silently failed and moving them again
results in a frightening
"disk error" message! However there is no apparent disk error, only
an Explorer bug:
the files eventually disappear, and appear in the destination
folder. A related phenomenon
occurs deleting files in which the files don't disappear right away
and trying the delete
again on the surmise that the first attempt somehow silently failed
produces the identical,
scary "disk error" message.
- Moving files sometimes fails with an error message saying the file
name is "too long or
invalid". This occurs despite the file name being unchanged, and
obviously short enough
and valid a moment ago. In fact, some experimenting has shown that
this is an explorer,
not a filesystem, issue, and that the length limit for file names
appears to actually vary
from one folder to another on the system.
The test: starting with a file in directory A that triggers this
bug when moved to directory B,
try to copy the file to directory B (rather than move it); it will
fail with the same bogus error
message. Copy it to C:\ instead; this seems to always succeed.
Rename it to "x.foo" from
whatever it was (keep the extension whatever it used to be) and
move this file to directory
B; this seems to always succeed. Now if you try to rename it back
to the original name in
Explorer, it will fail to paste the name in when you hit Ctrl+V,
and if you type it in manually
it will start silently ignoring your typing at some random-seeming
point. You can, however,
successfully rename it back using the command prompt -- but the
resulting file is in Weird
Mode now. Rename it (command prompt or Explorer) to "x.foo" again
and it stops being in
Weird Mode. In Weird Mode, the file will not show a thumbnail (if
applicable) and Explorer
will refuse to show (status bar or tooltip) any applicable metadata
and it can't be opened,
deleted, or much else but renamed from Explorer (but the command
line is another
matter).
This suggests that no NTFS file name length limit is being reached,
but a separate
Explorer one is, one that (oddly) is individual to each folder on
your hard drive.
Another experiment shows that Explorer fiendishly prevents you
working around this by
recreating a folder that develops a too-short limit.
Finding that folder A accepts an N-character file name but folder B
inconveniently does
not, you may cleverly decide to recreate folder B, and hope to draw
a longer name limit for
B in the lottery this time. Since folder A got a limit generous
enough for your purposes, it
is not on its face an unreasonable guess that maybe you can
fortuitously recreate folder B
and get a limit comparable to A's this time. So, you create a
folder C in B's parent
directory named "temp", move everything from B to "temp", delete
the now-empty B, and
rename "temp" to B's old name, and then move the file from A.
It will fail, consistently, every time you try this.
As a variation, you may move the file from A to "temp" before
renaming "temp" to B's old
name. This will work, but the moment you rename "temp" to B's old
name, the moved file
goes into Weird Mode (see above)!
It seems that Explorer uses Weird Mode to punish you for cheating
its name limit; any
name over the folder's limit puts the file in Weird Mode if
explorer is unable to prevent you
bringing the circumstance about to begin with with the "too long or
invalid" message.
Systematic obstruction of the user's goal is the order of the day,
once again.
Moreover, it seems that the name limit, though variable from one
directory to another, is a
deterministic function of the directory's location, name, and
contents. In the process of
recreating directory B above, in the final step, renaming "temp",
you give the new directory
all of the characteristics of the old one -- the location had been
the same, and all of the old
one's files were in it, and now the name is the same as well -- and
the limit becomes the
same as before.
The limit can be, for some directories, unreasonably short, too --
well under 100
characters; any sane OS or shell should tolerate names of at
minimum 256 characters,
and preferably of any length subject to the amount of available
swap space. Programmers
have had the luxury of being able to use variable-length strings
for at least 20 years. In
most modern languages (C++, Java...) it is extra work to limit
string lengths than to let
them fit the input size; only the primitive C char array
implementation is awkward for
unlimited-length strings. Even Pascal handles strings fairly well.
There's really no excuse for this one.
* Coasters:
- Explorer can lock up on attempting to browse or copy files from a
homemade, damaged
CD. I have a circular plastic denial-of-service attack right here
in this room; if inserted into
the Media Center Edition PC with the 64-bit CPU and copied to a
directory on the hard
drive, the system hangs.
* Information-gathering:
- Viewing a directory sometimes incorrectly shows a spinning
flashlight for ages instead of
the files, even if you'd been there two minutes earlier seeing
files, switched away, and
switched back. This makes sense for slow directory loading over a
congested network but
not viewing local folders, which should work in real time.
- (Possibly related) Viewing a directory that contains files
sometimes shows an empty
directory and a status of "Searching for items..." without a search
having been performed.
- Hovering over a file sometimes fails to produce a tooltip. Same
with a taskbar icon or tray
icon. Sometimes browsing elsewhere and hovering produces a tooltip
and then returning
and hovering over the original object of interest produces the
tooltip in a timely fashion, and
sometimes not.
- (Possibly related) Tooltips for tray apps sometimes begin to appear
behind, instead of in
front of, the taskbar, so that all but the top bit of yellow
balloon is obscured, making these
tooltips unusable. Once this happens, it consistently happens until
a reboot.
- Explorer enters an abnormal mode from time to time that lasts
anywhere from a few
seconds to several whole minutes. While it is in this mode,
selected files do not show
status information other than file size. Metadata such as bit rate
or dimensions fail to
appear. No user action seems to kick it back into normal mode. This
seems to be related
to the first tooltip abnormality noted above, as when this abnormal
mode occurs, tooltips
also fail to appear when hovering over any files whatsoever.
Selecting and deselecting
things or hovering over other files and then the original file
again often gets you the desired
tooltip, but in this abnormal mode situation, fails uniformly.
It is worth noting that this is one of several instances where all
of several distinct
mechanisms for accomplishing a particular user goal suddenly quit
functioning correctly at
the exact same time, indicating systematic obstruction of the user
goal rather than just
random buggy behavior. This suggests the possibility that some of
these oddities actually
result from the actions of an adversary -- despite the machine
possibly having no network
connection active at the time and nobody else having physical
access to the hardware. In
this instance, hovering over a file for a tooltip is one way to get
metadata and selecting it
and checking the status bar is another, and both fail
simultaneously, implying that getting
metadata is being systematically prevented rather than one method
for doing so happening
to quit functioning randomly.
In "abnormal mode" all Explorer status bars show blank, except that
one of them in some
window or another may instead show "Searching for items...",
despite no recent use of the
search tool by the user.
- Folders in thumbnail view spontaneously change to tile view, or
filmstrip, or some such
now and again. There's a half-life of about three weeks, which
means on a system with
many such folders I'll trip over at least one that has been changed
every day. Annoying in
the extreme.
- Tree view windows sometimes hang when redrawing. When this happens,
it is invariably
just before a directory with tens of thousands of files in it would
appear in the left-hand
tree-view pane. For example if bar, baz, and foo appear near the
top of the list, and foo has
40,000 files, and you enable tree view for that window causing a
tree view with bar, baz,
and foo at the top of the list to appear, it will show bar and baz
and lock up with the rest of
the view undisplayed. That explorer window will not respond (and if
you switch away, then
back, it either incorrectly won't switch to it at all, or the
window will be an empty white
box) for a long time, and then foo will appear in the tree-view
pane below baz.
Later, returning to the window or scrolling foo back into view will
work quickly -- for a while.
At some point (especially after a "spontaneous refresh spasm" as
described at the start of
this whole list of Explorer oddities) such an action will cause it
to redraw more slowly than
normal and, once again, lock up upon encountering foo.
It seems something it does is scaling with the number of files, and
maybe even
quadratically, whereas displaying not the contents but just the
name and icon of a folder
should take constant time.
- Sorting is quadratic in the number of files.
- A folder's sort order sometimes changes spontaneously, generally
from something else to
"by name". The half-life for a given folder and consequences for
general usage are similar to
those described for view settings spontaneously changing.
- If a folder is a working area for images, and as such sometimes
contains many images,
sometimes a few, and sometimes no files of any sort, every so often
"sort by dimensions"
stops being available spontaneously without explicit user choice.
It can be put back by a
painstaking process of menu and dialog fiddling using "choose
details...", which is a pain.
And this change won't stick: after a while, "sort by dimensions"
will disappear again. And
again. And *again*. This shows a similar half-life to the sort
order and view settings
randomly changing. All three bugs are probably related and probably
involve some saved
data getting corrupted with a certain probability, and then
reinitialized from defaults when
it is found to be corrupt, each time certain events occur (such as
changing view settings
somewhere else, requiring data be saved).
- Deleting a folder that's gotten into an odd state (such as no
filenames displayed in
thumbnail view) and recreating it doesn't fix the problem -- like
the bogus filename length
limit, these things seem to be saved somewhere and remembered even
after you delete
something, and if you recreate it, the saved settings (undesirable
though they might be)
are once again associated with your recreation. This has two
implications:
1. Deleting a folder never fully recovers the space its creation
consumed. Corollary: your
disk space will increasingly be consumed by memorized file name
length limit integers,
thumbnail view name showing booleans, and other cruft for
nonexistent directories,
irreversibly shrinking its usable space.
2. Any of these settings that you find got undesirable values can
only be changed by
a) Renaming or moving the problem directory permanently;
b) Finding how the setting can be altered and altering it.
For the "no filenames in thumbnail view" one, it seems changing
the view to tiles, then
right clicking, view->, and *shift*-clicking "thumbnails"
toggles it.
For the directory-dependent name length limit, there is no
method I am aware of to edit
(e.g. increase) the limit in that directory. Moving or renaming
the directory gets you a
new (perhaps more generous) limit, but any future directory with
the same name and
location as the old inherits the stingy limit that the old
directory had drawn.
* Deleting files:
- Deleting a bunch of files sometimes appears to have silently
failed. Trying the delete again
produces a scary "disk error" message, and the selected files then
actually disappear.
See above.
* Window positions and saving data:
- Windows sometimes spontaneously move. This only happens when you
can't observe it,
i.e. when a fullscreen app is running, such as a game.
- There appears to be no way to manually save the open-windows and
other data. If the
explorer process terminates abnormally, this state is lost and one
must painstakingly
recreate it. This includes if the system itself dies abnormally,
such as due to a power
failure. Worse, the result isn't just an out of date set of
reopened windows and their
locations; it is no reopened windows at all.
* Search:
- Searching sometimes omits files you know are there, even after
enabling "show hidden
files/folders". This includes ordinary files in ordinary
directories anyway. It seems
especially likely if you repeat a search, as if it's using outdated
cached data.
* Thumbnails and picture/fax previewing:
- Thumbnails sometimes fail to generate, or disappear after already
having been generated.
This occurs with or without generation of thumbs.db files being
suppressed. In the
"abnormal mode" noted above, thumbnails will not generate.
- Thumbnails fail to generate, or are generated as blank white
squares, during "super
abnormal mode" (see below).
- Picture/fax previewing produces spurious "drawing failed" when
viewing valid jpeg files
sometimes; this is an early symptom of "super abnormal mode" (see
below).
- The "refresh thumbnail" command fails in "super abnormal mode" (see
below) and,
randomly, at other times.
- Some generated thumbnails fail to represent the image content (as
observed with the
previewer, for instance). All of the following have been observed:
x A weird hash or colorful static
x Blank (esp. in "super abnormal mode" (see below))
x An image resembling the actual image, but substantively different
in some way
The last is especially curious, because often I can think of no way
that the thumbnail
shown could have been computed from the image data. For example, a
p2p-downloaded
image of a fancy car shows a thumbnail of a fancy car. When
previewed, a large fuschia
box containing a text URL (i.e., spam) is obliterating much of the
car, including the right
front wheel well and tyre. In the thumbnail, the right front wheel
is actually visible, barely.
How is Explorer able to infer the wheel from an image in which
there is nothing but pink
pixels there?
Refresh Thumbnail may randomly fail (see above); if it does not, it
will make the thumbnail
consistent with the image, but for that particular file, it will
sometimes spontaneously
revert to the same abnormal thumbnail as before, necessitating
doing this frequently. Also,
any of the following will cause it to revert every time:
x Rebooting
x Moving or renaming the affected file
x Moving or renaming any parent directory of the affected file
- The Picture/Fax Previewer, when started by double clicking on a
file, takes a positive
amount of time to start up. (Expected.) The amount of time it takes
scales with the
number of files in the same directory as the double clicked file.
(Should be constant time.)
- Moving back through the directory's files is slower than moving
forward inside the
previewer.
- When zoomed, moving back or forth by keyboard stops working, which
makes
flipping-comparisons of two images (to make differences leap out as
illusory "motion" to
the human visual apparatus) at full zoom impossible. Often this is
when you need it (e.g.
to compare two differently encoded versions of one image to see if
one has noticeably
worse compression artifacts, when the image is taller than the
desktop resolution).
- Picture/Fax previewer doesn't open multiple instances, making
side-by-side (instead of
flipping) image comparisons impossible, exacerbating the above.
* Poor scaling behavior of algorithms:
- Tree view windows sometimes hang when redrawing. When this happens,
it is invariably
just before a directory with tens of thousands of files in it would
appear in the left-hand
tree-view pane. For example if bar, baz, and foo appear near the
top of the list, and foo has
40,000 files, and you enable tree view for that window causing a
tree view with bar, baz,
and foo at the top of the list to appear, it will show bar and baz
and lock up with the rest of
the view undisplayed. That explorer window will not respond (and if
you switch away, then
back, it either incorrectly won't switch to it at all, or the
window will be an empty white
box) for a long time, and then foo will appear in the tree-view
pane below baz.
Later, returning to the window or scrolling foo back into view will
work quickly -- for a while.
At some point (especially after a "spontaneous refresh spasm" as
described at the start of
this whole list of Explorer oddities) such an action will cause it
to redraw more slowly than
normal and, once again, lock up upon encountering foo.
It seems something it does is scaling with the number of files, and
maybe even
quadratically, whereas displaying not the contents but just the
name and icon of a folder
should take constant time.
- The Picture/Fax Previewer, when started by double clicking on a
file, takes a positive
amount of time to start up. (Expected.) The amount of time it takes
scales with the
number of files in the same directory as the double clicked file.
(Should be constant time.)
- Sorting is quadratic in the number of files.
* "Super abnormal mode":
This occurs only after going a few days without a reboot. How soon
seems to depend on
how much use of thumbnail views and the previewer has occurred since
the last reboot, and
it correlates also with how bloated Explorer has gotten (VM size in
Task Manager).
It is a progressive, degenerative disease, as if the running instance
has developed
Alzheimers, which can be cured by exiting and restarting Explorer
(from Task Manager;
loses all your open window positions and locations, so you have to
reopen and renavigate to
all the directories you'd been working in) or rebooting (doesn't,
unless super abnormal mode
had progressed far enough, in which case this loses that state also).
The first symptom is that the previewer stops working correctly, and
for images with a large
width (>1500pixels) it claims "drawing failed" even though you know
the image is a valid file
(e.g. you previewed it earlier and it worked, and the image file has
not been modified in the
interim). The previewer initially views all files in the early
stages, but flipping back and forth
to compare images acts wonky if the images are wide enough: view A
(works), hit
right-arrow (works), hit left-arrow (fails). At this point the
failure is either with "drawing failed"
or hanging "generating preview..." without progressing past that
point.
Later, it consistently "drawing failed"s on wide images, and the
threshold width becomes
progressively narrower. Only width, not height or total image size in
bytes or similar, seems
to matter.
As it grows worse, folder windows don't redraw properly, thumbnails
turn to white squares or
to boxed file icons and need manual refreshing, and eventually
thumbnails just plain won't
work at all, even with explicit refreshing.
Super abnormal mode, in short, makes all work with images, both
thumbnail and previewer
based, progressively become impossible, and all related UI
progressively unusable.
My guess is it's actually a window handle leak in Explorer, probably
in the previewer.

.