Explorer weirdness

"Nebulon" wrote in message
oups.com...
c wrote:
"Nebulon" wrote in message
oups.com...
Nebulon wrote:
wrote:
*bump*

Why is this thread being ignored???

OK. Time to crosspost it where it might see some attention.

"weirdness""?

State the weirdness in detail.Then and only then you may
receive help.

I *did*. Has nobody read any of the posts? They go into a great deal of
detail. It sounds like you've only read the subject line, and there
isn't enough room to go into any detail there!

Someone " *bump*"
So I have not seen OP.The subject is all I receive and the flames.Even if
you crossposted,I still do not see the original post.

C.

"Nebulon" wrote in message
oups.com...
Nebulon wrote:
wrote:
*bump*

Why is this thread being ignored???

OK. Time to crosspost it where it might see some attention.


http://search.netscape.com/ns/search...e=NSCPResultsT

State the weirdness in detail.Then and only then you may
receive help.
I *did*. Has nobody read any of the posts? They go into a great deal of
detail.

oh hey there guys, I will dump his post for yah (once again, you gotta
love google... or hate it).


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.

c wrote:
"Nebulon" wrote in message
oups.com...
Nebulon wrote:
wrote:
*bump*

Why is this thread being ignored???

OK. Time to crosspost it where it might see some attention.


http://search.netscape.com/ns/search...e=NSCPResultsT

here is my search
http://groups.google.com/groups/sear...thor%3ANebulon

wrote:
State the weirdness in detail.Then and only then you may
receive help.
I *did*. Has nobody read any of the posts? They go into a great deal
of detail.

oh hey there guys, I will dump his post for yah (once again, you gotta
love google... or hate it).
snip

No need. He's been placed on "IGNORE" for his ****y attitude.

relic wrote:
wrote:
State the weirdness in detail.Then and only then you may
receive help.
I *did*. Has nobody read any of the posts? They go into a great deal
of detail.

oh hey there guys, I will dump his post for yah (once again, you gotta
love google... or hate it).
snip

No need. He's been placed on "IGNORE" for his ****y attitude.

How can that be? You were ignoring me *before* I showed any "attitude".
The original post to the thread was simply totally ignored, for no
obvious reason.

Nebulon wrote:
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.

Nebulon wrote:
Nebulon wrote:
[snip]

*bump*

Oh, and dragging and dropping a file doesn't usually place it at the
I-beam if the source and destination window are distinct. Instead, the
file appears at the bottom of the list. Sometimes it even appears where
dropped, and after a second or so spontaneously jumps to the bottom of
the list!

A couple more renaming wackinesses -- I've had f2 a) silently fail (and
then consistently do so until you switch tasks a couple times, or do
something such as sort the view differently; just changing the
selection and then changing it back *won't* fix this); b) occur
spontaneously. Select a file and sometimes after a short time it
abruptly acts as if you'd just hit f2. Your hands may be nowhere near
either keyboard or mouse at the time; click and move your hands away
from the desk immediately and watch and wait.

This gets annoying because sometimes a *double* click behaves this way
too. Sometimes, you double click an item and it becomes selected, but
fails to actually activate (preview, open, run, or whatever it should
do when double clicked). When this occurs, *invariably* after a short
time Explorer acts like you hit f2.

This isn't correlated, so far as I can see, with how rapid the
double-click is. So it isn't a too-widely-separated pair of clicks,
followed by the single click spontaneous-f2 behavior.

Nebulon wrote:
Nebulon wrote:
[snip]

*bump* again

Couple more I remembered (because they happened again recently):

* Shift-click selection behavior is buggy. If you sort a directory and
then click one item and shift-click another the correct behavior always
occurs, but if you manually rearrange the order in which the files are
displayed (drag/drop) or drop in new files from elsewhere, or another
process creates or moves a file to the directory, this is no longer
guaranteed. Sometimes in a no-longer-sorted directory shift-clicks act
like plain clicks (they change the selection to be just the item
clicked on). Other times, they select a range, but with gaps or even
extra files selected that weren't between the start and end of range.

* Shift-arrows and shift-mousing don't always work properly, especially
if the system or specific application is sluggish. It is possible to
release the mouse button first, then shift, and have the computer
behave as though you released shift first, then the mouse button. This
obviously has catastrophic consequences for your selection. Ditto shift
and an arrow key. It seems to be a general common-controls problem,
since it afflicts nearly every Windows app. It may even be an event
dispatch bug, since it seems to affect Java with apps with lightweight
components (Swing) -- suggesting Windows is not guaranteeing that a
pair of input events actually get queued in the order they occurred,
and then processed in the order they were queued, even when the two are
handled by the same thread of the same app.

* I've occasionally managed to get directory listings with blank spaces
in them (yes, even with auto arrange on). Difficult to reproduce.

* Dragging a file from window A to window B sometimes hangs both
windows for a time; renaming a file in a window sometimes hangs that
window for a time. Occasionally, other Explorer windows hang as well,
the task bar buttons no longer function, the Start menu no longer
functions, and/or the system tray no longer responds to input as well.

This last seems to be a case of it carrying out some lengthy
calculation in the UI event handling thread instead of the separate
thread where any such calculations clearly belong. Oddly, it does so
for a single file rename or move sometimes, but only rarely without any
obvious trigger differentiating the occasions when it does from those
when it doesn't. A multiple-file move, likewise, normally generates a
dialog if it isn't done nearly instantly; but occasionally (without any
obvious correlations) there's a freeze before the dialog appears.

Explorer recovers from these in maybe 10-20 seconds, so they aren't
drastic, but they can be a nuisance.

* Alt-tab to a nonresponsive app doesn't always focus its
(nonresponsive) window. If it doesn't, a subsequent alt-tab starts at
an incorrect position in the icon sequence (not the currently focused
window, but rather the one it failed to switch to. In fact, it should
always start at far left, and on these occasions, and only these
occasions, it starts in the middle!)

With Explorer often temporarily unresponsive there's plenty of
opportunities to get tripped up by this one trying to navigate. Picture
this: you do something and Explorer hangs. You alt-tab to something
else, e.g. Web browser or Solitaire, and do something else for a bit,
then alt-tab back. Nothing happens. So you go to alt-tab to something
yet else, such as email, and it starts in the wrong place...

* Poss. related: if you just renamed one file and arrow to another and
hit F2, the insertion point doesn't always start at the far right
position. (If you didn't just rename another file first, it does always
start at the far right.)

* Drag and drop operations that encounter a problem (other than
overwrite-existing-file) simply stop. All of the files not afflicted
with the problem should move, leaving only the afflicted file(s);
instead, the first afflicted file encountered and a whole bunch of
others that it would have moved after that one all get left behind.
This behavior is inconsistent with logic and with the
overwrite-existing-file case. This also applies to mass deletes.

* Occasionally, drag and drop moves seem to generate *copies*. The
general pattern is click A, shift-click-and-start-dragging B, let go
shift, and drop at destination. In any directory with work being done
to organize its contents, sometimes a file foo.bar is copied to "copy
of foo.bar" without any explicit user action (such as, say, right
dragging foo.bar and choosing "copy" from the resulting menu).

Context menus:

* The context menu sometimes fails to appear on cue. When this occurs,
the right click has in fact instead caused the window to hang. Tabbing
away and back wakes it back up, and the menu generally appears as
expected immediately upon right-clicking a blank space again. Possibly
related, sometimes the context menu works flawlessly until you select
"new "; then the submenu either fails to appear or appears as an empty
grey box and the window wedges. This time task switching is useless,
and the menus actually stay displayed for a while (on top of everything
else, blocking you from getting something else useful done while you
wait, of course). Eventually the menus vanish and the parent window
unfreezes. If you try the operation a second time, it invariably
succeeds flawlessly.

These seem to be a combination of a) a buggy caching algorithm and b)
doing something lengthy or that blocks on I/O in the event handling
thread.

It seems the menu items are cached somewhere, but for some stupid
reason the cache doesn't persist indefinitely. Every so often
(sometimes on successive occasions less than five minutes apart) the
cache ... disappears. Or maybe it doesn't, but Explorer thinks it did;
this would help explain the serious memory leaks mentioned earlier in
this thread. That's item a) above. Item b) is then that reloading the
cache (probably involving disk I/O) isn't done in an asynchronous
thread. Idiots!

* A similar thing happens with Start - Programs as with context -
New. Again, it works many times in a row, then hangs. This one is
easily the worst of the two, because the result is invariably a useless
grey box covering nearly the entire screen and preventing you from
being able to accomplish anything at all (or, at least, see wtf you're
doing) until Explorer unwedges itself.

* Selecting "new folder" from the context menu produces the behavior of
"new shortcut" instead, about one time in thirty. This one seems to be
completely random, while the previous two menu goofs seem to obey a
"seismic gap" law and occur at widely-spaced, somewhat evenly-spaced
intervals (modulo the frequency with which the potential trigger
action, e.g. right clicking in an Explorer window, occurs).

* Right clicking a blank space in a Filmstrip view window fails to give
the expected results 9 times out of 10. Only very thin regions between
two of the four thumbnails at the bottom seem to "work correctly";
other blank space produces a context menu appropriate for if you'd
right clicked on one of the file thumbnails or names or the larger
thumbnail in the top half. In particular, any right click in any white
space above the lower thumbnail row acts as if you right clicked *on*
the upper preview rather than *to one side* of it.

There's maybe 10 pixels in a Filmstrip view that you can actually right
click on to get the folder's context menu instead of one file's, if
there are four or more files. This view is almost unusable for file
organizing (rather than previewing, for which the double-click-accessed
previewer is available anyway and gives larger-resolution previews)
because only four files are shown at a time (or the total number, if
less than or equal to four). To add annoyance, changing it pretty much
necessitates a trip up to the View menu in the menu bar, because right
clicking to get the View submenu of the context menu is a crapshoot due
to the blank space bug discussed extensively in the last paragraph. The
final blow is that if a folder is changed from filmstrip view to, say,
thumbnail view (any other view, for that matter), it won't bloody STAY
that way! As detailed in the first post to this thread, it will
eventually spontaneously revert to a Filmstrip view without any user
intervention. This takes an average of less than a week for some
folders, but it varies from folder to folder and some never revert back
or only do so after weeks or even months. Frequent access seems to
reduce the risk (which is in stark contrast to most of the explorer
bugs that exhibit random tendencies; those usually show a fixed risk,
like the new folder behavior noted earlier, or become increasingly
likely to trip with frequent access and with time since the last
similar incident, like the popup menu and Start menu hangs.

The upshot of this thread is pretty clear now -- trying to organize
files on an industrial (rather than one or two files here or there)
scale in Explorer, and especially when they're photos, is a bloody
nuisance, not because the user interface contract makes it so (the way
it does with *every* photo-organizing app I've tried) but because the
user interface disobeys its contract frequently but unpredictably, the
application itself leaks memory and window handles (and when you work
with images, outright hemorrhages both), and the app is prone to
freezes and hiccups because it does tasks that potentially block on I/O
in the event-dispatch thread, computationally intensive tasks in the
event-dispatch thread, and some of the latter have poorly-scaling
algorithms: the sort seems to be O(n^2) instead of n log n, displaying
a directory in the tree view pane is sometimes O(n) in the number of
files inside the directory (even if it's not the selected one!) and
sometimes the more rational O(1) (more randomness!), and launching the
previewer on a file is O(n) in the number of files in the same
directory as the launch file (rather than the logical O(1)). If it's
caching information about the directory contents in the latter two
cases, fine, but can't it do so asynchronously?

Now I want to know three things:
1. Is there some way to work around any or all of these
bugs/hiccups/annoyances with exploder?
2. Is there at least a file management tool with image previewing
capabilities that lacks these sorts of shortcomings and is at least as
usable as Explorer would be without the bugs discussed in this thread?
3. Why have you all been ignoring this thread until now? It's been days
since the first post, without anyone other than me responding! That is
abnormal; a post seeking questions/advice/info in a high-traffic usenet
group normally gets one within hours (although it's by no means
guaranteed to be either useful or polite in my experience).

Nebulon wrote:
Gah. Two mo

* This one is especially irritating: select a file, scroll a long, long
way to find a second file, and then go to add to the selection. This
means shift- or control-clicking that second file. But sometimes, the
instant you hit the shift or control key the scrollbar decides to
behave as if someone else just dragged it. Invariably, all the way back
to the vicinity of the first file you clicked.

There is a workaround for this bug (unlike most of them): always tap
shift or control (whichever you intend to use later) after selecting
the first file and before scrolling to the second file. The workaround
works because this is one of those bugs with a refractory period: once
triggered, it lies dormant for a while before it might happen again.

* With a tree view in the left pane, the scroll wheel is supposed to
scroll whichever pane you last interacted with. It doesn't always.
Sometimes it scrolls the tree view pane at left even when the previous
action you'd taken was to do something in the right hand pane, such as
scroll it with the scrollbar or bring up a context menu. (Actually
changing the selection in the right pane seems to ensure that the next
scroll wheel flick will scroll that pane rather than the left one,
however.) Once again, though, this behavior doesn't seem to be
especially consistent. That is indicated by the left pane scrolling
surprising me sometimes when I expected the right pane to scroll; if it
behaved in any sort of regular fashion its predictability would make it
quickly have ceased to be surprising (but not annoying).

Nebulon wrote:
Would you believe *another* one just happened?

This one's actually consistent and reproducible, which is probably a
first for Microsoft bugs.

Go to any Explorer window in tiles view with a large number of files
(dozens, preferably 100). Scroll to the bottom, and then click a file
to select it and immediately (without more than a quarter second delay)
whip the mousewheel up.

The window will scroll up (correct) and then back down (wrong, wrong,
WRONG!)

And it then stops responding to the scroll wheel until you pause and
then start rolling it again.

This has the annoying effect of enforcing a delay between selecting a
file and moving off to either a) select another file far away, or a
lengthy range, or b) put the file there.

A related annoyance: there doesn't seem to be a fast way to move a file
a) a long distance inside one directory or b) to a subdirectory if no
tree view is displayed. Dragging the file to the destination position
or subfolder goes only slowly; and if it went more rapidly it would be
hard to reach a specific point without overshooting, aside from the
very top or very bottom. There's no apparent way to select a file,
scroll up (not dragging it), and then do something to place the
selection at the mouse pointer. (Well, maybe cut and paste? But I don't
want to delete the files and recreate them, only move them...and that
wouldn't work for subdirectory moves anyway. Deleting and recreating
has side effects and risks. One side effect is to change the creation
date. One risk is that the power goes out between cut and paste and the
files are just plain *gone*. The system could crash, too; and some apps
are poorly behaved and randomly clobber the clipboard from time to
time...)

Naturally, MS in their infinite wisdom forgot to implement the "scroll
wheel scrolls the focused window pane" feature completely -- if you
have something stuck to your mouse pointer, scroll wheeling does
nothing instead.

For subdirectory drops, you can manifest the tree in the left pane to
generate a drop destination. This carries risks (tree view redrawing
can hang for hours, if there's a directory with 50,000 files in there
somewhere). You can also open the subdirectory as a new window. This is
difficult (you can either right click and "explore", which causes the
risks of a tree view, or you can use Start-My Computer and navigate
there in the new window) and risky (one or more directory changes
occur, and each one risks the "everything spontaneously refreshes"
glitch that was the very first Explorer annoyance mentioned in this
thread, and if you already have a delicately-constructed selection to
drop into the new window and this glitch strikes, may God have mercy on
your soul ... and the ears of everyone else within swearing-range of
you when it happens...)

Nebulon wrote:
Nebulon wrote:
I have a whole shopping list here Major Snip

Too much. Shorten it if you want some one to actually read it, or live with
it.



--
Posted via a free Usenet account from http://www.teranews.com

Dustbin Kook wrote:
Nebulon wrote:
Nebulon wrote:
I have a whole shopping list here Major Snip

Too much. Shorten it if you want some one to actually read it, or live with
it.

Excuse me?

I listed the issues I am experiencing. I want information about how to
work around, prevent, bypass, or whatever *all* of them. It's certainly
not MY fault that MS software is buggier than a bait store!

Are you saying that I can only ask for help with some of the bugs
because Microsoft included so many? That's not fair -- that punishes me
for Microsoft's errors.

Or are you just suggesting a separate thread per bug? Because that
means starting about 50 new threads...

Nebulon wrote:
Dustbin Kook wrote:
Nebulon wrote:
Nebulon wrote:
I have a whole shopping list here Major Snip

Too much. Shorten it if you want some one to actually read it, or
live with it.

Excuse me?

I listed the issues I am experiencing. I want information about how to
work around, prevent, bypass, or whatever *all* of them. It's
certainly not MY fault that MS software is buggier than a bait store!

Are you saying that I can only ask for help with some of the bugs
because Microsoft included so many? That's not fair -- that punishes
me for Microsoft's errors.

Or are you just suggesting a separate thread per bug? Because that
means starting about 50 new threads...

I had to go into Google groups to read your post because this message that I
am replying to is the only message I see in OE. It was hard to get through
your list because my eyes went blurry and my brain zoned out. I don't get
any of that wierdness in Explorer on any of the machines I work with. I'm
not saying that there aren't buggy things on your machines, or that there
aren't irritations with the OS, I just don't see your bugs on my machines
and I haven't had any complaints from my users about the bugs you see.

Neither of the last two posts (claiming that the problems observed are
specific to my system) are correct.

If either of you had read the original posts carefully, you'd have
noticed that these problems have all been observed, personally by me,
on multiple machines, machines which had little in common besides being
Windows PCs.