On Tue, 27 Mar 2007 08:59:51 +0100, "Gerry Cornell"
Chris
Hi!
Might your "namespace" issue explain some bizarre problems I have with
Search? I cannot get a correct return for "cash.xls". It gives me
"cash1206.xls" and all variants of cash........!
Ah, but there are so many other reasons why Vista Search may behave
unexpectdly, that one's tempted to keep it on probation, following it
with Agent Ransack searches straight after, until your use of it has
refined to the <cough> high power-user standards it expects.
See other threads in and around here. Issues seem to be:
1) Order and inclusivity
Usually story - you say "search here" but it may dither around
elsewhere first. It seems to go; indexed locations, then somewhere
else according to some criteria I forgot (C:\Users, maybe?) and then
it may, or may not, search within the "everywhere" you selected.
The last works-by-default search was in WinME; with XP, you always
have to go Advanced, show hidden and system files, even if you already
set these to be visible in Explorer (and therefore are one of those
folks who trip over non-navigable junctions, LOL)
2) Name vs. content
This may be UI-specific (i.e. apply to those single-input-field
"simple" UI) but you may intend to search for names that match a
filespec, but the serach will grope content instead.
3) Spaces and wildcards
As you know, spaces are taken as a delimiter unless closed within
quotes. But you may expect that when used as a delimiter, the
different delimitered items are OR'd together, e.g...
Search( *.EXE *.COM *.CMD *.SCR *.BAT *.PIF *.CPL )
....would be expected to find file types that canm run as raw code when
"opened". But in Vista, and possibly in XP (where I find I have to
use "comma space" rather than just "space") the items are AND'd
togther. So you do the above search to exclude infectable code files
in your data set before backup, say, and you get the expected "none
found", and yet there may be who knows what septic stuff in there.
What you may also assume is that "Some Name*.exe" will find "Some Name
1.exe", "Some Name Here.exe" etc. via * as a wildcard. But this is
not what happens in Vista, I'm told (from threads here"; instead, the
* is taken as a literal, unless you precede the "quoted string" with
the tilde character (i.e. tilde != "not" in this case), e.g.
Search( ~"This will match * as a wildcard.txt" )
4) The usual stuff...
....such as matching strings within binary, ASCII and Unicode content.
Also this comment interests me "C:\Users\{UserName} to D:\, ". I have
placed my Data files in H:\ DATA having never used any My Documents
folders! Is Microsoft saying you can only use our system without
problems if you conform to our mandatory User Account structure?
Hmm.. not really, you can manually put your data elsewhere, tho later
permissions issues may apply if defaults for access are tightened up.
It's more about whether apps will default to the location you want, if
they use (or statically derive) their data paths from shell namespace.
The small challenge in Vista is how to get Vista to map an existing
shell space location to path of your choice, without:
- duplicating the namespace item in the C:\Users... view
- botching the name of the target directory
- losing "special" behaviours such as folder icon, view
- dropping the Desktop.ini or leaving it in the wrong place
- stranding data of already-installed apps (i.e. do this first)
The large challenges are:
- how to do all that for the new account prototype
- how to create your own namespace folders and behaviors
--------------- ---- --- -- - - - -
Saws are too hard to use.
Be easier to use!
