Recovering vanished directories

[Mike Barnes]

Despite my best effort, I committed the same mistake as I was setting
up my new Lenovo Z400 Win8 notebook with a touch display. I lost some
application directories with their content and I had to do a full
restore from the recovery partition to start with a fresh slate again.
I wish that Windows Explorer wasn't that eager to anticipate every move
and wait for a deliberate action from the user. Something like what a
double click fixes from inadvertent errors from a single click.

Isn't that what a right-button-drag does? It seems to me to be designed
for exactly your needs.

Speaking for myself I'm very happy with the way everything works at the
moment - I generally left-button-drag and look before I drop, and I
would be impeded by any extra steps. If at all unsure (generally when
creating a shortcut) I right-button-drag instead.

 

[nukid]

My thought too.

Oh, it's definitely worse with Windows, though it's considerably worse
with Vista than with Windows 7.

I've got one of each here and:

* Explorer -- prone to spazzes of high CPU use that slow all other apps
down to stuttery wonkiness for a second or two, but only on the Vista
box. Of course, lowering Explorer's priority lowers that of everything
you launch subsequently, as they inherit Explorer's priority, so the
only way to make Explorer's CPU spazzes less annoying is to *raise*
priority for *everything* *else*, one application at a time. And then
it *still* doesn't seem to help much -- for some reason, Vista's
scheduler is wonky enough that I often see an application with "above
normal" priority get slow and stuttery whenever some other task with
"normal" or even "below normal" priority starts grinding the CPU.
Explorer is particularly prone to be a culprit, probably because M$
decided to give Explorer the ability to "cheat" and elevate its own
priority invisibly to do some things.

Did I mention that all of this is much, much *worse* if Indexing Service
is not disabled? But the 7 box seems OK.

* Windows Defender -- Not something I tend to actually interact with, but
from time to time I'll be working when whatever I'm using slows to a
crawl. If it's not Explorer hogging the processor, it's a good bet it's
the svchost.exe hosting Windows Defender, and while Explorer sucks down
a good 20-30% CPU when it spazzes, Windows Defender saturates a whole
core. Fortunately, giving that particular svchost.exe "below normal"
priority solves it until the next reboot.

* TrustedInstaller -- If it's not Explorer *or* Windows Defender. Most
common for the first hour or so after a post-Patch-Tuesday reboot, but
happens sporadically at other times as well. Saturates one core, natch.

* Photoshop -- Well behaved once running, but there's a brief period
during its startup when the whole machine can freeze for as much as 30
seconds. Nothing responds and sometimes even the mouse pointer gets
stuck for a while, incredibly. That should not be possible without the
"assistance" of badly-behaving code that runs in kernel mode, and no
other app I use provokes this. It's probably looking for a scanner
driver or something like that. Since the pointer can freeze during
this, the operating system is indubitably at least partly to blame, and
not just the user-mode application.

* Firefox -- On the Vista box, frequently freezes for several seconds
when changing tabs, particularly if the tab or, especially, the
application has been idle for a while. Weirder than that, it will
frequently spontaneously navigate temporarily to a randomish page
(unpredictable exactly which page, but not unbiased) from my history
(and render it wonkily), then freeze, and return to where it was on
unfreezing.

Its favorite site to visit while it freezes? Youtube, where often
nothing but the Flash box will display, with some recently-viewed video
paused inside it, and the rest of the page just a blank black or white
for the most part.

I've not seen this behavior on the 7 box with the exact same versions of
Firefox and Flash installed, so Vista's got something to do with it,
unless it's wonky Firefox behavior that only happens on less powerful
hardware -- but it *should* just be incrementally slower on less
powerful hardware, at least as long as you don't go all the way down to
sub-GHz machines from the 90s or something. Instead there's specific,
non-linear and even step-function behavior, and while the machines'
hardware specs differ along a continuum, Vista vs. Windows 7 is a step
function change in operating system and much more plausibly the culprit
for step function changes in application behavior.

* Anything that's written in Java -- On the Vista box, *will* freeze if
left idle for a while and then switched to, for upwards of *five
minutes*, then *usually* spontaneously start working again. If it was
minimized, however, it's got about a 20% chance of freezing for five
minutes and then crashing instead.

The same versions of the same applications don't freeze or crash under
W7. On the other hand the W7 box also has Java 7 (or is it 1.7?)
installed rather than Java 6 (or 1.6). *Maybe* Java 7 is better behaved
rather than Vista sucking. But it's similar to the difference in
Firefox behavior, and Firefox isn't implemented in Java.

* Everything else -- If it's more complicated and powerful than
Notepad.exe, it's liable to be unresponsive for a minute or so if it's
left idle, then switched to. Switching to it, immediately switching to
something else to work on something else for a bit, and then switching
back usually works as a workaround, but it's a nuisance to have to do
this. Most applications seem to "wake up groggy" if they've been
inactive for a while under Vista and older versions of Windows. This is
much less pronounced, or absent, so far in my experience with Windows
7, though.

But, no matter what Windows version, if an application decides to grab a
lot of processor, stuttery behavior in other applications occurs. Making
user interface event loops (unless they started using processor heavily
themselves) automatically elevated in priority would have been a nice
design choice for Microsoft, but they didn't bother.

Failing that, they could at *least* have made a single, interleaved
stream of input events, and saved current mouse coordinates into
mousedown and mouseup events. Then if you moved the mouse to X and shift-
clicked, dragged to Y, and released, the system would always interpret
those inputs the same way -- it just might take longer if something was
hogging the CPU.

Instead, keyboard and mouse events seem to have their own queues and none
of the events are either a) timestamped or b) stamped with the current
mouse coordinates when generated. So the above inputs become a shift-down
and shift-up in one queue, without timing information, a mousedown and
mouseup in another queue, without timing or location information, and an
application that's bogged down can end up processing shift-down, then
shift-up, then a mousedown, then it queries for the current mouse
position and gets position Y by the time it's chugged to this point, then
it finally processes the mouseup when the mouse has moved to Z, resulting
in an unshifted drag from Y to Z instead of what the user actually input,
which was a shifted drag from X to Y.

And that's just bad design, and it's bad design that didn't improve in
W7, as near as I can tell, too. Mouse events as generated by the OS
should include the location and current modifier-key states rather than
an application polling or tracking these possibly after the mouse has had
time to travel farther and a modifier might have been released. And mouse
and keyboard events should be combined into a single stream, thus not
able to end up handled in the wrong order because some component
somewhere was slow in responding.

 

[nukid]

[snip rant about Windoze spazziness and how the UI is designed assuming
that everything will be snappily responsive]

Oh, and I just remembered: there's another bit of UI wonkiness.
Inconsistently, if you click on something, then click somewhere before
the first click visibly takes effect, the second click can "act as if"
the first click has already had its effect, *or* not, inconsistently. Of
course the application has to be sluggish in responding to the first
click for this effect to be observed.

For example, click a menu heading, get no visible response, click again.
A second or two goes by, then the menu drops down and instantly retracts,
as if you'd clicked, it had dropped down, and *then* you'd clicked again.
Shouldn't two clicks on a not-dropped-down menu be treated as two
commands to *expand* the menu, not as if the first click dropped the menu
down and only then was the second click input? This gets very annoying if
an application is slow enough that it misses some mouse events.

And now for the inconsistency: if I click, say, the file menu heading,
then (before it appears, as the app is being sluggish) click the spot on
the screen that *will* be occupied by the Save As menu item once the
first click takes effect, do I get a pause, then the menu flickers
briefly and a Save As dialog pops up?

NOOOOOOOOOOOOOOOOOOOOOOOOOOO!

I get the menu flicking briefly and then the cursor repositioned to the
location of the second click in my document window, or an object
selecting in that position, or some other such behavior, as if the second
click did *not* happen while the menu was down (and its Save As item
under the cursor). On the other hand, the menu dismisses *precisely* as
it would if the click happened *when* the menu was in its dropped-down
state, but else*where* on the screen than inside the menu's bounding box.
Incredible! That scenario is inconsistent even inside of itself, with the
document acting like the second click happened where it did and before
the menu dropped down (as was actually the case), but the menu itself
acting like the second click happened *after* the menu dropped down but
*elsewhere on the screen* than it did. And this is if I don't nudge the
pointer one pixel in between inputting the second click and the mouse
moving.

Also, for a clear-cut case of a single, specific application being
unresponsive under Windoze (any version) and not under Linux, try the
Gimp. Download and install the current version on a W7 box and a Gentoo
box, then load up a big (say, 50 megapixel) image in it and rotate by an
amount that's not a multiple of 90 degrees. You'll get a nifty circular
progress indicator, like a clock, slowly filling in green in a clockwise
direction in the center of the image window.

After about two seconds, on the Windoze box it will probably hang.

The GIMP will actually complete the rotation operation and become
responsive again afterward, but the progress indicator stops updating and
becomes useless much sooner, only on Windows.

Adding yet another bit of wonkiness to this, this behavior is
*inconsistent*. The progress meter will *occasionally* keep working ...
unless you switch to another window and then go back after a while to
check on Gimp's progress, whereupon you'll discover the progress meter
hung up at the point it was at at the moment you switched away. It won't
update again until the operation is completed. Again, only on Windows.

This happens regardless of how you switch away, incidentally -- alt-tab,
click in taskbar, click part of another application window not covered by
Gimp windows, etc. -- and regardless of how you switch back.

As I understand it, the progress indicator in question is directly drawn
by the Gimp onto the drawing surface supplied by the host window manager,
using code that isn't different in its essentials in the Windoze port, so
this pretty much has to be broken behavior by the WM and not by the
application. And, of course, under Windows, any misbehavior of the WM is
ipso facto Microsoft's fault, since they don't provide the capability to
drop in third-party alternatives to their own dwm.exe.

Hey, did I mention yet that sometimes drag-and-drop gets sluggish and
wonky in Explorer and Process Explorer will show dwm.exe eating up to 2/3
of a core at the time? No? Well, now I have.

Did I mention that sometimes drag-and-drop simply *breaks* and the only
way to get it working again is to reboot? Yeah, once that happens, the
mouseup event leaves a "turd" on the screen in the shape of whatever the
drag-icon was, at the position of the drop, and the receiving application
doesn't see a drop event. Sometimes closing an application or two makes
it start working properly again for a while, but it invariably breaks
again within a few minutes. Explorer windows also all stop auto-
refreshing when directory contents change when this happens (and this
stays broken even if drag and drop is temporarily fixed by closing, say,
Gimp or Photoshop) but it's not an Explorer-specific problem. Drag and
drop simply stops, period, in or between any applications. I can't drag
mail from Inbox to Archive in TB or drag a decoded binary from Xnews to
an open VLC window or etc. either.

I've yet to see the above feature-specific system crash (and that *is*
what it is, if nothing short of a reboot provides more than a very
temporary reprieve) with Win7, though, only Vista. On Vista it correlates
with uptime, but not perfectly. Shorter sessions have had it happen, but
only if they were also heavy on drag and drop file reorganizing in
Explorer. This in turn suggests that Vista actually grants users a
limited number of drag operations per reboot, for some insane reason,
with, even more kookily, running processes counting against the limit as
well, but reversibly. That is, there's some counter somewhere with the
property that:

* It's zero after reboot.
* Starting a process increments it, and closing a process decrements it.
* Performing a drag and drop operation increments it.
* If it's greater than some threshold, the "drop" half of drag-and-drop
will be ignored/suppressed at the OS level, leaving the drag icon frozen
on the screen and the would-be receiving application not seeing a drop
event.

Or at least something similar. (Processes might add and substract a
different number than 1, for example, even perhaps different per process;
or drag and drop operations might count for a different or varying
amount; or the whole scale could be shifted, or reversed to make it a
countdown to zero instead of a countup to some threshold, or whatever.)

Who in their right mind would program such a counter into Vista (and
possibly other Windoze versions)?

Still, I'm mostly satisfied with W7 at this point...

 

[nukid]

That scenario is inconsistent even inside of itself, with the document
acting like the second click happened where it did and before the menu
dropped down (as was actually the case), but the menu itself acting
like the second click happened *after* the menu dropped down but
*elsewhere on the screen* than it did. And this is if I don't nudge the
pointer one pixel in between inputting the second click and the mouse
moving.

Dammit, that *should* say "And this is if I don't nudge the pointer one
pixel in between inputting the second click and the application
responding to the clicks."

 

[Char Jackson]

1. Sometimes Ctrl-z works, but it seems not always.

2. Get into the habit of using a right click drag. Then when you release
you can choose your poison from a pop-up menu.

3. But *don't* get int the habit of choosing without looking (a real
danger, not a joke).

IMO, drag and drop of either flavor is way overused by the general public. I
frequently hear from people who have experienced a drag and drop accident
that could have been avoided if they had instead used cut or copy and paste.

 

[Gene E. Bloch]

IMO, drag and drop of either flavor is way overused by the general public. I
frequently hear from people who have experienced a drag and drop accident
that could have been avoided if they had instead used cut or copy and paste.

OK, but after all, my mistakes have been relatively few, far between,
....and disastrous

 

[Char Jackson]

OK, but after all, my mistakes have been relatively few, far between,
...and disastrous

....but you're not the average bear...