Indexing - oddities persist/increase (Dave Wood...?)

[Guest]

Hope you're listening Dave...[doubt anyone else has any inclination to wade
through this ]

Started a new thread as the previous Indexing Questions thread got long...

Do let me know what you make of this if you can,

Thanks

Julian

Specifics
=======

The indexing/search oddities persist/increase.

I finally found UNCFATPHInstaller for indexing via UNC paths via an article
on the knowledgebase. Installed fine.

From Explorer, my Steganos Safe being mounted as Z:, I shared this drive,
reckoning that if it was shared, it would then have to have a UNC path

In Indexing Options I was able to successfully add this UNC location, and
sometime later when the index was complete, the count of indexed files had
increased from ~36,000 to ~62,000, the entities in Z: being ~26,000 in number
by an Explorer properties examination.

However - with one (!,?) exception, I can find nothing on that drive.

The exception is the folder "Fragments - Current" which is not at root
level, and the tooltip in the Search results list says it is at
"Z:\Prose\Fragments". [though it is annoying that the location is not always
given in the tooltip... rarely in fact... additional comment at end]

Now I confess that before sharing the drive I attempted to add the UNC path
\\pcname\Z: - and that also seemed to work (though as I recollect I didn't
get a "was successfully added" confirmation at that time - though I did later
after sharing and adding the new path). Evidence that it worked is that I was
presented with a folder hierarchy, and was able to select individual folders
for indexing, and... some time later... the item count was commensurate with
the number of items expected. I tried this because, without scripting skills
I have no idea

But I could only find "Fragments - Current" as above.

Very important to note that before I shared the drive and added it (with
confirmation of success from Vista) as a proper UNC path (\\pcname\private...
no ":" and all in lower case) I reset Indexing, restarted and confirmed that
all previous inclusions had gone.

-----------
More data on strange search results:

I also note (re gam/game/game* oddities) that "gameux" produces no hits, but
"gameux.dll" does... (just the one "gameux.dll") now, gameux.dll is in
system32 - a non-indexed location - BUT searching for "gam", and going to the
location for "Games Explorer" takes me to
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Games - and Start Menu
IS indexed. Yet within that location is the desktop.ini that associates the
..lnks with user presented names and paths to... gameux.dll.

..ini files are indexed and they have a Plain Text filter, so the question is
why hasn't gameux or gameux.dll been recorded as being in there?

[using | as delim because i want to show where I used quotes] Not also that
"Purple Place" is found by |pu|, |pur| but not by |purp|...|purpleplace| or
|"purpleplace"| or |"purple place"|, but is found by |pl|...|place|

--------
Search result tooltip comments re location of result

1. If I have several files (e.g. desktop.ini) or folders of the same name, I
can't tell which content item is where from the result list
2. Why just sometimes/some types?
3. Can it be controlled - i.e. forced on?

 

[Dave Wood [MS]]

I'm not sure on the network drive stuff - I don't know anything about
Steganos Safe and whether it's supported. I'll try to investigate and get
back to you.

The Start Menu does search the windows\system32 directory but I think only
for the full name of a dll or exe. It doesn't do partial matching in that
scenario so you would need to type the full gameux.dll name.

As for why the contents of desktop.ini files aren't being indexed - I think
it's because they are System + Hidden files which don't get indexed. You can
see this if you do Start -> Search and then search for desktop.ini - you
don't see any of them. So I think this behavior is all as expected {if a
little confusing}.

PurBle Place is spelt with a "b", not a "p". I have no idea why ...

You're talking about in the Start Menu search if you have multiple items
with the same name? Yes, I think the lack of folder paths in the tooltips
has been reported before - I'll make sure the right team has that feedback
for the future. Note that generally the items control their tooltips, not
Start Menu itself - remember we search all kinds of things like mail items
which don't usually have a file path so there has to be a mechanism for
those kinds of results to show a tooltop.

Note you can always open the full Search window by going to Start -> Search
and doing your searches there which will show paths.


Dave

Hope you're listening Dave...[doubt anyone else has any inclination to
wade
through this ]

Started a new thread as the previous Indexing Questions thread got long...

Do let me know what you make of this if you can,

Thanks

Julian

Specifics
=======

The indexing/search oddities persist/increase.

I finally found UNCFATPHInstaller for indexing via UNC paths via an
article
on the knowledgebase. Installed fine.

From Explorer, my Steganos Safe being mounted as Z:, I shared this drive,
reckoning that if it was shared, it would then have to have a UNC path

In Indexing Options I was able to successfully add this UNC location, and
sometime later when the index was complete, the count of indexed files had
increased from ~36,000 to ~62,000, the entities in Z: being ~26,000 in
number
by an Explorer properties examination.

However - with one (!,?) exception, I can find nothing on that drive.

The exception is the folder "Fragments - Current" which is not at root
level, and the tooltip in the Search results list says it is at
"Z:\Prose\Fragments". [though it is annoying that the location is not
always
given in the tooltip... rarely in fact... additional comment at end]

Now I confess that before sharing the drive I attempted to add the UNC
path
\\pcname\Z: - and that also seemed to work (though as I recollect I didn't
get a "was successfully added" confirmation at that time - though I did
later
after sharing and adding the new path). Evidence that it worked is that I
was
presented with a folder hierarchy, and was able to select individual
folders
for indexing, and... some time later... the item count was commensurate
with
the number of items expected. I tried this because, without scripting
skills
I have no idea

But I could only find "Fragments - Current" as above.

Very important to note that before I shared the drive and added it (with
confirmation of success from Vista) as a proper UNC path
(\\pcname\private...
no ":" and all in lower case) I reset Indexing, restarted and confirmed
that
all previous inclusions had gone.

-----------
More data on strange search results:

I also note (re gam/game/game* oddities) that "gameux" produces no hits,
but
"gameux.dll" does... (just the one "gameux.dll") now, gameux.dll is in
system32 - a non-indexed location - BUT searching for "gam", and going to
the
location for "Games Explorer" takes me to
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Games - and Start
Menu
IS indexed. Yet within that location is the desktop.ini that associates
the
.lnks with user presented names and paths to... gameux.dll.

.ini files are indexed and they have a Plain Text filter, so the question
is
why hasn't gameux or gameux.dll been recorded as being in there?

[using | as delim because i want to show where I used quotes] Not also
that
"Purple Place" is found by |pu|, |pur| but not by |purp|...|purpleplace|
or
|"purpleplace"| or |"purple place"|, but is found by |pl|...|place|

--------
Search result tooltip comments re location of result

1. If I have several files (e.g. desktop.ini) or folders of the same name,
I
can't tell which content item is where from the result list
2. Why just sometimes/some types?
3. Can it be controlled - i.e. forced on?

 

[Guest]

OK - I feel a bit of an idiot (ok, total idiot) about "purBleplace" - can't
believe I looked at it so much and didn't spot that... gorilla on the
basketball court effect?

I'm not sure on the network drive stuff - I don't know anything about
Steganos Safe and whether it's supported. I'll try to investigate and get
back to you.

Thanks...!

Semi-rhetorically, whether it is or isn't supported what is confusing is
that a UNC path can be given and at the very least all the contents
counted... how do you do that without getting all the file/folder names? [see
below - I think we ARE getting them...] and if not actually indexing the
indexable content why did it take so long to complete?

And if I give it a UNC path doesn't the OS opening support the rest of the
protocol? (I'm definitely on tiptoe in deep water here...)

NAIVELY... it's a mounted drive, explorer is happy with it, it looks just
like any other drive... why shouldn't it be amenable to Indexing? Even within
Indexing locations I can expand all the sub-folders so the evidence from here
and the item count is files/folders are accessible.

And now the breaking news of 30s ago... just typed \\pcname\private (the
shared name of the mounted Safe) and wow! there are all the sub-folders...
and if I keep on expanding the path eventually filenames start appearing....
I do hope this means they *are* in the index - I read somewhere recently in
the forums that Start Search ONLY uses indexed search). So... I can find
things provided I know where to look How do I get to filename searching
regardless of location?

The Start Menu does search the windows\system32 directory but I think only
for the full name of a dll or exe. It doesn't do partial matching in that
scenario so you would need to type the full gameux.dll name.

It's the apparently sheer arbitrariness of some of this which makes it such
an aneurysm inducing experience! OK... no partial matching in system32 is a
fact.

As for why the contents of desktop.ini files aren't being indexed - I think
it's because they are System + Hidden files which don't get indexed.

I knew that, I was just testing... I wish!

Good point! If I show Hidden files my guess would be that they are now
visible Hidden files, rather than non-Hidden and that wouldn't affect their
searchability? I know with full searches I can search system and hidden files
- any way to force indexing?

I expect the debate was "who would want to... why? It can't be that
important" but it's when something's got very weird with a large and complex
system that you want to be able to find things anywhere, quickly. I'd let it
index overnight and then all my digging around the next morning would be
fast...

I could choose an example but it would not be an instance of a problem that
affects millions of users, it would however be one of millions of problems
each of which affects just a few (call them googlebugs... a term I hereby
assert my moral authority to be identified as the author of... for all the

You're talking about in the Start Menu search if you have multiple items
with the same name? Yes, I think the lack of folder paths in the tooltips
has been reported before - I'll make sure the right team has that feedback
for the future.

Thanks again... sometimes it's nice to be listened to, sometimes it's even
nicer to be heard (well, as long as one's not talking nonsense... purPle

Note that generally the items control their tooltips, not
Start Menu itself - remember we search all kinds of things like mail items
which don't usually have a file path so there has to be a mechanism for
those kinds of results to show a tooltop.

Sure, but if there is a path because it's an item in the file system it
would be nice.

Note you can always open the full Search window by going to Start -> Search
and doing your searches there which will show paths.

I'm sorry Dave, I'm afraid I can't do that.

....searches that don't find anything sometimes never stop (usually evidenced
by the green progress bar overwriting the red cancel X) so it's a bit of a
last resort... knowing when something can't be found because it isn't there
or hasn't been found (yet) can be tricky with this issue c.f. Theology -
the search in a darkened room for a black cat that isn't/may_or_may_not_be
there.

Dave, my satisfaction with MS rises every time I can have such a meaningful
dialogue - thanks. If we can advance this any further I will be even happier!

Julian

 

[Dave Wood [MS]]

I have a couple of quick points:

- Regular Hidden files work the way you say - we index them and show them if
you have selected to "show hidden files and folders". But desktop.ini's are
*System* Hidden files, which are "special". You need to go to Start ->
Search -> Advanced and select "Search non-indexed, hidden and system files"
to search for them.

- The primary aim of Start Menu search is finding apps, plus finding
documents, music etc. that you could also find in Start -> Search. So the
Start Menu search does something similar to Start -> Search, plus it also
searches Control Panel, installed apps etc. etc. Searching the
windows\system32 is a fallback for the few cases where there are exes there
that aren't in the Start Menu. Basically there's a perf / completeness
trade-off - the Start Menu could search the whole drive, but you'd be sat
waiting for a really long time to get results. Start Menu perf is a really
important consideration {I assume - I didn't work on the Vista Start Menu}.

- Similar trade-offs exist with what we do or don't include in the index. If
we indexed every file on the drive then searching would be fast and easy,
but the perf of the rest of Windows would suffer. So we don't index the
whole drive by default. Also some files that typically change very, very
frequently would endlessly be reindexed, so we don't index those {FANCI
bit}. Also some files we know are binary so we don't index their contents
{.exe and .dll}. Sometimes it would be nice to be able to search the
contents of .exe files as if they were text {if you are a developer}, but is
it worth the extra resource load on everyone's machine just for the handful
of people that need to do this? So yes we do have tough trade-offs to make,
but in most cases if you change the search settings from the default you can
get the behavior you want. I'd agree that it's not as easy to control the
search experience as we'd like and that's something we do need to work on in
the future.

I'm sorry Dave, I'm afraid I can't do that.

- LOL! Unless you change the scope then Start -> Search will only search
indexed locations, so it should be fast. If you can give details when it's
not that would help us. But note if you search from an explorer window at an
actual location like C:\ or Computer than it will search everything, and
that may be slow {non-indexed search}.

Dave

OK - I feel a bit of an idiot (ok, total idiot) about "purBleplace" -
can't
believe I looked at it so much and didn't spot that... gorilla on the
basketball court effect?

I'm not sure on the network drive stuff - I don't know anything about
Steganos Safe and whether it's supported. I'll try to investigate and get
back to you.

Thanks...!

Semi-rhetorically, whether it is or isn't supported what is confusing is
that a UNC path can be given and at the very least all the contents
counted... how do you do that without getting all the file/folder names?
[see
below - I think we ARE getting them...] and if not actually indexing the
indexable content why did it take so long to complete?

And if I give it a UNC path doesn't the OS opening support the rest of the
protocol? (I'm definitely on tiptoe in deep water here...)

NAIVELY... it's a mounted drive, explorer is happy with it, it looks just
like any other drive... why shouldn't it be amenable to Indexing? Even
within
Indexing locations I can expand all the sub-folders so the evidence from
here
and the item count is files/folders are accessible.

And now the breaking news of 30s ago... just typed \\pcname\private (the
shared name of the mounted Safe) and wow! there are all the sub-folders...
and if I keep on expanding the path eventually filenames start
appearing....
I do hope this means they *are* in the index - I read somewhere recently
in
the forums that Start Search ONLY uses indexed search). So... I can find
things provided I know where to look How do I get to filename searching
regardless of location?

The Start Menu does search the windows\system32 directory but I think
only
for the full name of a dll or exe. It doesn't do partial matching in that
scenario so you would need to type the full gameux.dll name.

It's the apparently sheer arbitrariness of some of this which makes it
such
an aneurysm inducing experience! OK... no partial matching in system32 is
a
fact.

As for why the contents of desktop.ini files aren't being indexed - I
think
it's because they are System + Hidden files which don't get indexed.

I knew that, I was just testing... I wish!

Good point! If I show Hidden files my guess would be that they are now
visible Hidden files, rather than non-Hidden and that wouldn't affect
their
searchability? I know with full searches I can search system and hidden
files
- any way to force indexing?

I expect the debate was "who would want to... why? It can't be that
important" but it's when something's got very weird with a large and
complex
system that you want to be able to find things anywhere, quickly. I'd let
it
index overnight and then all my digging around the next morning would be
fast...

I could choose an example but it would not be an instance of a problem
that
affects millions of users, it would however be one of millions of problems
each of which affects just a few (call them googlebugs... a term I hereby
assert my moral authority to be identified as the author of... for all the
good it will do me<g>) to which one access route of common utility seems
to
be reasonably tightly shut.

You're talking about in the Start Menu search if you have multiple items
with the same name? Yes, I think the lack of folder paths in the tooltips
has been reported before - I'll make sure the right team has that
feedback
for the future.

Thanks again... sometimes it's nice to be listened to, sometimes it's even
nicer to be heard (well, as long as one's not talking nonsense... purPle

Note that generally the items control their tooltips, not
Start Menu itself - remember we search all kinds of things like mail
items
which don't usually have a file path so there has to be a mechanism for
those kinds of results to show a tooltop.

Sure, but if there is a path because it's an item in the file system it
would be nice.

Note you can always open the full Search window by going to Start ->
Search
and doing your searches there which will show paths.

I'm sorry Dave, I'm afraid I can't do that.

...searches that don't find anything sometimes never stop (usually
evidenced
by the green progress bar overwriting the red cancel X) so it's a bit of a
last resort... knowing when something can't be found because it isn't
there
or hasn't been found (yet) can be tricky with this issue c.f. Theology -
the search in a darkened room for a black cat that isn't/may_or_may_not_be
there.

Dave, my satisfaction with MS rises every time I can have such a
meaningful
dialogue - thanks. If we can advance this any further I will be even
happier!

Julian

 

[Guest]

Just had an OMG moment...

The AE35 is fully functional... after all.

I thought that Start Menu search and Start->Search did the same
things/returned the same results (except that the latter also had Advanced
non-index searching as an option.)

Just tried Start->Search for things on that Steganos safe shared as
\\pcname\private and EVERYTHING is there.

Why did I think the search functionality was the same??? Don't know. The
results could hardly be more different, even disregarding the inclusion of
Control Panels etc. on Start Menu search.

The differences should be noted somewhere in letters a mile high!

Re perf tradeoffs etc... where there is a possibility of choice (i.e. not
breaking the system) the more choices you give users the happier they will be
(as long as there's always a "return to nominal settings" option too...).
This is I think MS biggest issue of principle... choosing for us when it
doesn't NEED to choose.

Anyway, I'm sorted out - thanks... now all I have to do is to see if the UNC
path to a mapped drive letter works or get a script to auto-share the mounted
drive

So long, and thanks for the fish

Julian

 

[Dave Wood [MS]]

Glad to hear you got this working! If you right click on the start orb,
select Properties, go to Customize and scroll down to "Search Files" there's
a "Search entire index" option, which I think will make the Start Menu
include all the results that Start -> Search does.

In general however, regarding choices, I respectfully have to disagree. Too
many choices are as bad as too few. Joel on Software has a good article on
this subject which puts it far more eloquently than I could:
http://joelonsoftware.com/uibook/chapters/fog0000000059.html

 

[Guest]

right click on the start orb, select Properties, go to Customize and
scroll down to

"Search Files" there's a "Search entire index" option

....to search the entire index rather than just this user's files, which was
the default option it seems.

Again, excellent info - thanks.

In general however, regarding choices, I respectfully have to disagree.
see Joel's http://joelonsoftware.com/uibook/chapters/fog0000000059.html

I appreciate the perspective, but with equal respect I shall continue to
disagree with both of you (I'm big on the philosophy of choice anyway at the
moment for reasons that don't belong here, so this is just a slice

Joel writes entertainingly and clearly and he makes his points well, but he
misses *the* point, as illustrated by the following two assertions that
feature prominently in his text:

1. "Asking the user to make a decision isn't in itself a bad thing"
2. "Every time you provide an option, you're asking the user to make a
decision."

*The* point arises from the fact that, unfortunately, neither of these
statements is necessarily true.

*Asking* a user to make a choice can indeed be a bad thing - the Help wizard
example is a classic example, a hangover from the days of smaller disks and
slower computers.

The problem however is not choice per se, but *requiring* a choice. It's the
interruption of the process by the very act of asking for a decision by the
user that's the issue.

It would have been better for the designer to provide a quick answer -
perhaps one that would take no longer than to exercise the choice actually
presented - based on the best choice that could be made at the design stage,
and in case the results were not helpful to *offer* the user the choice of
repeating the search more slowly (maximised index).

Point 2 is clearly related: the existence of options does not require the
user to make a choice unless you first decline to make a choice yourself.

It seems very simple: do the best you can as designers and developers, and
if the result is not what the user requires (which only they can decide at
the time) tell them that it can be done differently. An item in the search
results list labelled "Can't find what you are looking for?" would be a good
for-instance here: click it and I would be shown a list of the locations
indexed, a statement on which parts of the index were used in my failed
search, etc. etc. and controls to allow me to do it differently - this time
only or always.

Joel's other great example was the moved and resized taskbar. The problem
again is not that placement and size is an option, it is the absence of an
Undo operation for this sort of thing: the implementation *commits* the user
to a choice that they may have been unaware of making. A global undo list on
a per object basis would be extremely powerful and could resolve all such
issues.

Many people are still intimidated by IT; I encourage those who ask me for
advice to explore the choices available with the observation on applications
that "you can usually undo everything, and if you can't, a well-written
program should warn you before you commit yourself" - it's good application
design, why doesn't it apply to the OS? Undo that window move, undo that
taskbar resize, undo that toolbar rearrangement, un-map that drive, etc.
Windows Key + Z perhaps?

Such a change in philosophy would not be trivial, I concede, but I think the
rewards would outweigh the costs.

The problem is not choice, it's declining to take responsibility for the
choices that have to be made - which necessarily include "do nothing".

I am not upset that MS makes choices about how to do certain things - it has
to; I do get frustrated when it also chooses not to allow me to choose
otherwise (or even tell me that I can) - when and if I might wish reasonably
to do so. The situation we have been discussing would seem to be a case in
point.

Thanks Dave,

Julian