Unfixed bug in Vista SP1 explorer.exe

More than a year ago, not long after Vista came out, I posted a description
of a bug here in this group (descriptions of three issues actually, this is
only about the third - I've learned to live with the other two).

A bit to my surprise, this issue has not been fixed in SP1.

It's the third bug in this post:

Message-ID: <> or
http://groups.google.co.uk/group/mic...c4aeb4f5a7817f

There was somewhat of a discussion about it later, the fact that it affects
only folders on NTFS formatted disks was discovered in the course of that
discussion.

A walkthrough showing how to recreate the problem using nothing but
explorer and cmd.exe can be found in Message-ID:
<>





To recapitulate: using Shift+Click to select a range of files in explorer,
on a volume that is NTFS formatted, creates a risk that whatever you
selected the files for will be applied to more files than you intended.

The problem did not occur with FAT volumes (at least not last year, I don't
have any to test it with right now.)

When events take place in this order:

1) You click (select) a file somewhere near the start of a folder.
2) An application (or you, in another window) creates one or more new
subfolders in that folder. New files will also do, if they precede the
file you selected in alphabetical order.
3) You shift-click a second file further in the folder, to expand your
selection to a range.

If this happens, Explorer will select more files than you told it to.
It may even go unnoticed in large directories, if the error takes place in
a part that's scrolled out of view.


What causes it is the fact that folders on NTFS are kept sorted in explorer
(folders on FAT are not, you have to refresh them).

New files and folders on NTFS appear immediately at their correct
alphabetic position. When you select a range by click and shift-click
however, explorer remembers the _position_ in the alphabetical list of the
first object you select, instead of its identity.
If the list is changed between click and shift-click, it takes the wrong
object as "first".

The bug you posted isn't in the OS, but with you.

Shift-Click is supposed to select all files from the one you originally
clicked until the one you just clicked.

The functionality you're looking for is Ctrl-Click which allows you to
select just the two files that you wish to work with.

"Luc" <> wrote in message
news:...
> More than a year ago, not long after Vista came out, I posted a
> description
> of a bug here in this group (descriptions of three issues actually, this
> is
> only about the third - I've learned to live with the other two).
>
> A bit to my surprise, this issue has not been fixed in SP1.
>
> It's the third bug in this post:
>
> Message-ID: <> or
> http://groups.google.co.uk/group/mic...c4aeb4f5a7817f
>
> There was somewhat of a discussion about it later, the fact that it
> affects
> only folders on NTFS formatted disks was discovered in the course of that
> discussion.
>
> A walkthrough showing how to recreate the problem using nothing but
> explorer and cmd.exe can be found in Message-ID:
> <>
>
>
>
>
>
> To recapitulate: using Shift+Click to select a range of files in explorer,
> on a volume that is NTFS formatted, creates a risk that whatever you
> selected the files for will be applied to more files than you intended.
>
> The problem did not occur with FAT volumes (at least not last year, I
> don't
> have any to test it with right now.)
>
> When events take place in this order:
>
> 1) You click (select) a file somewhere near the start of a folder.
> 2) An application (or you, in another window) creates one or more new
> subfolders in that folder. New files will also do, if they precede the
> file you selected in alphabetical order.
> 3) You shift-click a second file further in the folder, to expand your
> selection to a range.
>
> If this happens, Explorer will select more files than you told it to.
> It may even go unnoticed in large directories, if the error takes place in
> a part that's scrolled out of view.
>
>
> What causes it is the fact that folders on NTFS are kept sorted in
> explorer
> (folders on FAT are not, you have to refresh them).
>
> New files and folders on NTFS appear immediately at their correct
> alphabetic position. When you select a range by click and shift-click
> however, explorer remembers the _position_ in the alphabetical list of the
> first object you select, instead of its identity.
> If the list is changed between click and shift-click, it takes the wrong
> object as "first".
>

On Wed, 25 Jun 2008 11:08:20 +0200, Luc <>
wrote:

>More than a year ago, not long after Vista came out, I posted a description
>of a bug here in this group (descriptions of three issues actually, this is
>only about the third - I've learned to live with the other two).
>
>A bit to my surprise, this issue has not been fixed in SP1.

Here's another surprise for you:

THIS AREA IS NOT MONITORED BY MICROSOFT for bug reports.

Or for anything else for that matter.

> Shift-Click is supposed to select all files from the one you originally
> clicked until the one you just clicked.> The functionality you're looking
> for is Ctrl-Click which allows you to select just the two files that you
> wish to work with.

No, the OP is right. He is using Shift-Click correctly - to select a range.
The point he's making is that the *start* point of the range moves if you
add any files or folders before selecting the end point of the range with
Shift-Click.

I've never wanted to use Explorer that way, so it seems like an obscure bug
to me. Strange they haven't fixed it, though. Maybe they don't know about
it.

Does anyone know the official way to report a bug to Microsoft? It's
certainly a waste of time posting it here.

SteveT

This is not Microsoft and bug reporting here is not going to reach your
intended audience. You can report bugs at
http://support.microsoft.com/?LN=en-us&x=15&y=11
Either use a solution center or the Contact Microsoft link in the left pane.
Vista is a released product and bugs need to be triaged by Product Support
Services before being passed on to a dev team. PSS gets the first shot at
resolving your issue or escalating to research.

You can also use
http://www.microsoft.com/globaldev/o...deaSubmit.mspx
to submit in the form of a suggested improvement.

"Luc" <> wrote in message
news:...
> More than a year ago, not long after Vista came out, I posted a
> description
> of a bug here in this group (descriptions of three issues actually, this
> is
> only about the third - I've learned to live with the other two).
>
> A bit to my surprise, this issue has not been fixed in SP1.
>
> It's the third bug in this post:
>
> Message-ID: <> or
> http://groups.google.co.uk/group/mic...c4aeb4f5a7817f
>
> There was somewhat of a discussion about it later, the fact that it
> affects
> only folders on NTFS formatted disks was discovered in the course of that
> discussion.
>
> A walkthrough showing how to recreate the problem using nothing but
> explorer and cmd.exe can be found in Message-ID:
> <>
>
>
>
>
>
> To recapitulate: using Shift+Click to select a range of files in explorer,
> on a volume that is NTFS formatted, creates a risk that whatever you
> selected the files for will be applied to more files than you intended.
>
> The problem did not occur with FAT volumes (at least not last year, I
> don't
> have any to test it with right now.)
>
> When events take place in this order:
>
> 1) You click (select) a file somewhere near the start of a folder.
> 2) An application (or you, in another window) creates one or more new
> subfolders in that folder. New files will also do, if they precede the
> file you selected in alphabetical order.
> 3) You shift-click a second file further in the folder, to expand your
> selection to a range.
>
> If this happens, Explorer will select more files than you told it to.
> It may even go unnoticed in large directories, if the error takes place in
> a part that's scrolled out of view.
>
>
> What causes it is the fact that folders on NTFS are kept sorted in
> explorer
> (folders on FAT are not, you have to refresh them).
>
> New files and folders on NTFS appear immediately at their correct
> alphabetic position. When you select a range by click and shift-click
> however, explorer remembers the _position_ in the alphabetical list of the
> first object you select, instead of its identity.
> If the list is changed between click and shift-click, it takes the wrong
> object as "first".
>

On Wed, 25 Jun 2008 05:08:27 -0500, Nonny <> wrote:

> THIS AREA IS NOT MONITORED BY MICROSOFT for bug reports.
>
> Or for anything else for that matter.

You'd be surprised

It's not because they don't mingle in flame wars and don't start giving out
free support, that the group is completely being ignored.

Some newsgroups (not this one though) are even very actively being
monitored, and if your posting alias is previously registered, a reply to
your questions by an MS engineer is guaranteed unless someone else answers
the question first (but that ain't free: you have to pay for an MSDN
subscription before you can register).

On Wed, 25 Jun 2008 02:42:22 -0700, "Shane Nokes"
<> wrote:

> Shift-Click is supposed to select all files from the one you originally
> clicked until the one you just clicked.

Yes, and it's not doing that.

It's selecting MORE files, as you'd be able to see if could you follow the
directions I posted in in Message-ID:
<>

I'd include a google groups link to that message, but something funny
happens: when the message ID is entered in google search it opens a window
with the right newsgroup name in the title, and then says "Message not
found". So it knows the message ID belongs to this group, but it doesn't
have a copy of the message.


So I'll repeat the steps here, you need an explorer window and a cmd.exe
window, both with the same current directory:


> Create/open an empty test folder in explorer, open a CMD window, and
> 'cd' to the same folder.
>
> Now first run this at the command prompt to create some files:
>
> C:\Test>for /L %i in (1,1,10) do echo Hello > %i.txt
>
> Now click on "5.txt" in the explorer window to select it.
> Next, run this at the command prompt to add some directories:
>
> C:\Test>for /L %i in (1,1,3) do md dir%i
>
> You'll see the new folders appear at the start of the file list in
> explorer. File 5.txt remains selected.
>
> Now shift-click "6.txt". You expect 5 and 6 to be selected now - see what
> happens instead.


And (I'm repeating myself, but just to be sure): it only does it on NTFS
disks, not on FAT.

On Fri, 27 Jun 2008 10:15:00 +0200, Luc <> wrote:

> So I'll repeat the steps here, you need an explorer window and a cmd.exe
> window, both with the same current directory:

One more thing: it seems to depend on the view type the folder is in, in
explorer. It does it in "list" and "details" views, but not on "medium
icons".

I'm thinking something odd has to be happening with your PC then that's not
happening with mine.

When I shift-click to select in anything below the icons segments in views
it picks the files in order properly.

For instance if I select a file and a file directly beneath it it's perfect.

Once I move into icon views if I'm select horizontal it works perfectly well
for selecting adjoining files.

It's not supposed to work vertically in icon views (it's supposed to select
everything in the horizontal grids prior) and not horizontally in the lower
views.

For me it's working exactly as intended.

"Luc" <> wrote in message
news...
> On Fri, 27 Jun 2008 10:15:00 +0200, Luc <> wrote:
>
>> So I'll repeat the steps here, you need an explorer window and a cmd.exe
>> window, both with the same current directory:
>
> One more thing: it seems to depend on the view type the folder is in, in
> explorer. It does it in "list" and "details" views, but not on "medium
> icons".

On Fri, 27 Jun 2008 21:14:52 -0700, "Shane Nokes"
<> wrote:

> I'm thinking something odd has to be happening with your PC then that's not
> happening with mine.

I've been able to reproduce it on multiple Vista machines now, not all of
which were my own. Actually, I haven't met a machine yet where I could
/not/ reproduce it when I tried.

The only thing I found that prevents it so far is not using NTFS formatted
disks.