Vista - Bug in Windows explorer can result in lost files

I believe I've found a bug in Windows Explorer that I can reproduce reliably.
If anyone can get this to a QA engineer in the Vista group at Microsoft, I'd
appreciate it. Here's how to reproduce:

1. Open the Windows explorer browser (not Internet Explorer). Set it up so
that you that you can see folders in the left-hand tree view panel and files
in the right-hand list panel.

2. Create a new folder called "Test" and a subfolder below it called
"TestSub".

3. In the SubTest folder, create three text files. Call them "Test1.txt",
"Test2.txt" and "Test3.txt". Just to make the files non-empty, open them up
and type a single character into each (I typed "x") and save.

4. In the left-hand tree view, click on any folder that is not in the Test
-> SubTest hierarchy.

5. Again from the left-hand tree view, single click on the "TestSub" folder.

6. In the right-hand list view, highlight just the files "Test2.txt" and
"Test3.txt" by holding down the left mouse button and dragging the cursor
over both files. The message "2 items selected" should appear in the
bottom-left of the window.

7. From the keyboard, click "Shift + Delete".

=> Vista pops a message saying "Are you sure you want to permanently delete
this FOLDER?" (caps mine)

8. If you click Yes, Vista deletes the subfolder "SubTest", including the
file "Test1.txt", which was not selected!

This is bad. Any reasonable user in this circumstance would expect that
Windows will delete the last selection, not the entire folder containing that
selection.

I am pretty sure this is a new problem starting with Vista. I used to use
the technique above to delete files in Windows 2000 and Windows XP all the
time, and I have saw this happen in those OSs. With Vista, I have lost files
as a result of this behavior because I have the admittedly bad habit of using
Shift + Delete and OK'ing through the warning box. (Fortunately I keep good
backups.) Still, Vista's behavior here is, in my opinion, incorrect.
Someone should start a bug report on this.

Dave


----------------
This post is a suggestion for Microsoft, and Microsoft responds to the
suggestions with the most votes. To vote for this suggestion, click the "I
Agree" button in the message pane. If you do not see the button, follow this
link to open the suggestion in the Microsoft Web-based Newsreader and then
click "I Agree" in the message pane.

http://windowshelp.microsoft.com/com...ile_management

"Dave" <Dave@xxxxxx> wrote in message
news:6BA556FD-4E62-4CF6-BF11-5341D05AD0CF@xxxxxx
Doesn't delete the subtest folder or test1.txt file here.

> Doesn't delete the subtest folder or test1.txt file here.

Really? I can reproduce this reliably, and I have Windows Update enabled,
so I assume I have the latest version of Vista Home Premium. winver.exe
reports Windows Version 6.0 (Build 6000).

Note that the instructions have to be followed very closely to reproduce.
Specifically, you need to first single-click the TestSub folder in the
left-hand tree view. Immediately afterward (without clicking anywhere else),
position the mouse pointer directly to the east of the file named
"Test2.txt". Then in one motion, hold down the left mouse button and drag
the cursor southwest until you have covered the files "Test2.txt" and
"Test3.txt". Now release the mouse button. Finally press Delete on the
keyboard (or Shift + Delete, doesn't matter). Windows will ask you if you
want to delete the folder "TestSub".

If you single-click anywhere in the right-hand panel after clicking the
TestSub folder but before highlighting the two files, then the problem
doesn't occur. Looks like the "Mouse Down", "Mouse Up" and "Mouse Drag"
events are not informing Explorer that the context has switched to the
right-hand panel. This is definitely a bug.

If you provide me an e-mail address or FTP address, I can send screen shots.
Just let me know.

Dave

"Dave" wrote:

Hi Dave

I also cannot recreate what you are describing here?

It appears that for whatever reason, the focus is being transferred properly
from the TestSub folder to the 2 selected files in the right side pane, even
though the details bar shows 2 files selected?

Give us some more details about where in the folder tree these folders are
being created. Also, what type of hardware are you using, wireless mouse or
keyboard or? What settings are you using in folder options, classic folders,
single or double click, etc.

Try using the mouse to right click, hold down 'Shift' and select the Delete
command in the context menu in step 7.

This is very interesting.

--

Ronnie Vernon
Microsoft MVP
Windows Desktop Experience


"Dave" <Dave@xxxxxx> wrote in message
news:6BA556FD-4E62-4CF6-BF11-5341D05AD0CF@xxxxxx

The key to reproducing this is that immediately after clicking on the folder
in the left-hand tree view, you need to "draw a box" in the right-hand list
view that implicitly selects one or more files. You need to start the box by
NOT clicking directly on the file itself, and you need to completely avoid
doing a normal single-click. I start by positioning the mouse pointer well
to the right of the file name. Then I press down on the left-hand mouse
button (don't release!) and drag the pointer to the southwest, drawing a
solid blue box that partially touches the files "Test2.txt" and "Test3.txt".
It may sound strange, but I actually use this technique all the time to move
files around.

I can actually reproduce this with just a single folder and a single file.
I create a "Test" directory right off the "C:" drive with a single, empty
text file called "Test1.txt" in that directory. Next, click on any folder in
the left-hand tree view OTHER than "Test". Now click on the "Test" folder in
the left-hand tree view. Then follow the instructions above.

I am using a Dell wireless mouse and wireless keyboard (Bluetooth), though
I'd be surprised if that made a difference. In terms of options, I'm just
using the classic Windows Explorer with a tree view of folders in the
left-hand panel and a list view of files/subfolders in the right-hand panel.
I'm using the "Details" view in the right-hand panel.

Let me know if you're able to reproduce with this information. If not, I'll
try digging up my older wired keyboard and mouse and see if that makes a
difference.

If you want to reach me directly you can e-mail me at davidamdur (at) gmail
(dot) com.

Thanks,
Dave

"Ronnie Vernon MVP" wrote:

Hi Dave

I'm not having any problem following your instructions, they are very clear.
I just cannot reproduce the behavior you are seeing.

The problem does appear to be a focus issue. Prior to dragging and selecting
the files, the focus is on the folder and dragging to select the files
doesn't appear to change the focus to the files that are being selected.
This is why you are seeing the message about deleting the folder instead of
the selected files.

A single mouse click is actually 2 separate functions. One is when you press
the mouse button and the second is when you release the button.

You can see this by clicking a folder that contains sub-folders, the
sub-folders will appear in the right side pane. If you position the mouse
cursor in the right side pane and press/hold the right mouse button, nothing
happens, but as soon as you release the right mouse button, the context menu
pops up. In this case, the press gave the right side pane focus and the
release caused the context menu to appear.

In this same scenario,you can also press and hold the right mouse button,
drag the cursor to select an area or a file/folder, but nothing will happen
until you 'release' the right mouse button which will then pop up the
context menu, completing the operation.

In the behavior you are describing, you press and hold the left mouse
button, drag to select the files and then release the mouse button. The
'press' appears to work properly, but the operation isn't complete until the
button is released and this appears to be where the operation fails.

The only difference between our testing appears to be that you are using
wireless hardware and I am using wired hardware. If it's not too much
trouble, try switching to a wired mouse and try to recreate the behavior.
--

Ronnie Vernon
Microsoft MVP
Windows Desktop Experience


"Dave" <Dave@xxxxxx> wrote in message
news:B3AF7A52-3195-42DD-95D0-0B402C104C94@xxxxxx

I just tried with a wired mouse and can still reproduce the problem easily.
I can't use a wired keyboard because my wired keyboard has a PS/2 plug and my
computer running Vista has only USB slots. Still, it seems unlikely that the
keyboard is the problem. Your assessment makes sense: it sounds like the
mouse drag operation (a combination of mouse down, mouse move, and mouse up
events) is not bringing focus to the right-hand panel.

What version/build are you running? I'm on Vista Home Premium, Build 6000.
Maybe this was fixed in a later build?

Dave

"Ronnie Vernon MVP" wrote:

Dave

Thanks for the info.

I have 3 Vista systems running here, 2 test systems with Home Premium and
Business and my production machine with Ultimate. The 2 test systems are the
original Build 6000 and the production machine is Build 6001 (SP1). I have
tried this scenario on all 3 with the same results.

I'll add this problem to my research list and also try to escalate it with
the Shell Team as far as I can. If I find anything I'll let you know with
the email address you provided and post the information to this thread.

There is also another feedback path to Microsoft, if you want to go ahead
and submit it there. They do read those feedbacks, but cannot respond
personally to each submission. Be sure and include a description of your
system in the report, they can usually recreate just about any type of
system when they test.

Vista Feedback Portal:
https://feedback.windowsvista.micros...ctkey=winvista


Take care,
--

Ronnie Vernon
Microsoft MVP
Windows Desktop Experience


"Dave" <Dave@xxxxxx> wrote in message
news:9F211AF3-9289-4A24-849B-2C885A326C15@xxxxxx

Cool. Thanks for reading all my posts! The only other thing that occurs to
me is that I'm on an AMD Athlon machine. It's probably a long shot, but I
did once encounter a bug in MATLAB that only cropped up only on AMD (as
opposed to Intel) boxes.

I'll send a feedback message through the URL you mentioned, too. Thanks
again.

Dave

"Ronnie Vernon MVP" wrote:

Dave

Your welcome, you did a good job in describing the behavior.

I doubt that the AMD is responsible, but who knows? Stranger things have
happened. <g>

One other bit of information is that, like many other components, Windows
Explorer was rebuilt from the ground up using .NET for the first time. There
may still be some errant bugs in there.

--

Ronnie Vernon
Microsoft MVP
Windows Desktop Experience


"Dave" <Dave@xxxxxx> wrote in message
news:52E4D122-DDF7-4EC4-B643-C221F88EF746@xxxxxx