How come Search won't find a file?

[micky]

How come XP Search won't find a file that is there?????

I set the partition to C: and the text to various things and it
woulnd't find the file.

I tried sessiion, sessionstore, sessionstore.js, sess*, and sess*.js .

Asterisks are acceptable in XP Search, aren't they?

Then I googled about Firefox and this file and found out from the web
where exactly it is, went there and found it, and made backup copies
of it and *.bak, and *-20.js, and almost by chance stored them two
directories higher, and those three files immediately showed up in the
still-open search window, without my clicking on Search again.

I presume XP search didnot find sessionstore.js because it's so deep
in the directory structure so that the fully qualified name is too
long for the Search function. Hard to believe since I didn't assign
the name, but when I make backup copies of sessionstore.js and .bak
and put them 2 levels higher in the directory, Search found them
immediately.

XP seems still bound by a DOS limitation on file name length! Or is it
a Windows 95 limit?

For people who have Firefox 3 or higher and who have the option turned
on to restart FF with the same windows and tabs.
(Tools/Options/General/Startup: When Firefox starts: Show my windows
and tabs from lafst time).

The full location is C:\Doecuments and
Setting\Administrator\Application
Data\Mozilla\Firefox\Profiles\nlnlnnll.default\sessionstore.js

where C: might be D:, Adminstratior might be another persona, n's are
numbers and l's are letters.. And more than one profile may exist,
but they contain very different things sometimes and only one was used
in your current or last session.

 

[Nil]

How come XP Search won't find a file that is there?????

I set the partition to C: and the text to various things and it
woulnd't find the file.

I tried sessiion, sessionstore, sessionstore.js, sess*, and
sess*.js .

Asterisks are acceptable in XP Search, aren't they?

Yes, asterisks are allowed.

Windows Search found it for me, so it should for you, too. Are you sure
you turned on the "Search system folders" and "Search hidden files and
folders" Advanced Options?

You made a bunch of spelling errors in your post - are you sure you're
spelling the file name correctly in your search?

 

[VanguardLH]

How come XP Search won't find a file that is there?????

Because starting with Windows XP and after, Microsoft changed the search
function to only list files for which it has a viewer. If it cannot
view the file (show it to you) then the search will pretend that it
never found the file. In Windows 2000, and earlier, content of the file
was irrelevant when doing a search. From Windows XP, and later, the
search function finds files it can view (show).

Get something better, like FileLocator Lite (used to be called Agent
Ransack but they decided that name wasn't appropriate for business use
as companies didn't like a product with "ransack" in its name). Not
only will it find all files (and you don't need to keep remembering to
click the Advanced option to ensure you included hidden folders and
files) but you can use more wildcarding and even regular expressions to
ensure that you find just the file you want. Instead of, say, searching
on "amd.com" and having "str-decamd.com" found in a search, you could
use "^amd\.com$" which anchors the start and end of the string (and
escape the period since that means "any 1 character" in regex) so
exactly "amd.com" gets found.

You could install file indexing software, like Live Search or Google
Desktop or Copernic Desktop, but eventually they get in the way, like
having a handle on a file that you want to delete or otherwise need
exclusive write permission.

I set the partition to C: and the text to various things and it
woulnd't find the file. I tried sessiion, sessionstore,
sessionstore.js, sess*, and sess*.js . Asterisks are acceptable in XP
Search, aren't they?

There are special folders and special files, even when you enable the
search to show hidden files, that no Microsoft search will ever find.
Those are considered system files that end users should not touch.
Their search will skip over those special objects. Even if you
configure Windows Explorer to show you system files, there are critical
files that it will not show by default or in search results. If you're
digging in there, you better had know what you're doing hence the need
for 3rd party software to get beyond Microsoft's special file
protection. It's the same with the registry. There are special or
critical values or keys that regedit.exe and reg.exe cannot access.

 

[micky]

The full location is C:\Doecuments and
Setting\Administrator\Application
Data\Mozilla\Firefox\Profiles\nlnlnnll.default\sessionstore.js

Yes, asterisks are allowed.

Windows Search found it for me, so it should for you, too. Are you sure
you turned on the "Search system folders" and "Search hidden files and
folders" Advanced Options?

Thanks, that did it!

I have hidden files visible in the Folder Optons, and didn't know I
have to set it here too.
Also, it's not the file that's hidden. Have to go all the way up
to Application Data to find the directory that is hidden. I don't
know about this because I always have everything unhidden.

I'm using a temporary computer, and may or may not have set this
correctely years ago in the usual computer.

Another intresting thing is that those two files that I moved up to
the Firefox directory.were still under the hidden drirectory, but they
showed up... for a while. When I looked at the results today,
whithout having run Search again, they were gone!!

Also. Application Data in winME was not a hidden file, which is why
it showed up.

I'm glad that they didn't screw up because of their own length
limitation, but I think the default on hidden should be whatever
Folder Options is set for.

You made a bunch of spelling errors in your post - are you sure you're
spelling the file name correctly in your search?

No that was not the problem. I'm also at a temporary location, with
the keyboard on a TV table and the monitor so far I have to lean over
to see it well, which is one reaosn I used ses*.js.

 

[micky]

Because starting with Windows XP and after, Microsoft changed the search
function to only list files for which it has a viewer.

That can't be true, because the same search found, in my backup
partition, the same file with the same extension. I suspect because
this was a backup of winME and the fully qualified name was much
shorter, it displayed it. (For the benefit of newbie readers, WinME
doesn't have separate personas and separate sets of application data,
so the file name is shorter. (Or because Application Data in winME is
not a hidden directory. After all, it's everyone's application data,
so why bother to hide it, I guess.)

If it cannot
view the file (show it to you) then the search will pretend that it
never found the file. In Windows 2000, and earlier, content of the file
was irrelevant when doing a search. From Windows XP, and later, the
search function finds files it can view (show).

Get something better, like FileLocator Lite (used to be called Agent

I'll look into that. I wouldn't mind another search program, although
there is little point to installing software on this temporary
computer.

Thanks.

 

[Nil]

Because starting with Windows XP and after, Microsoft changed the
search function to only list files for which it has a viewer.

I don't think that is accurate. It may true be for Vista and up, but
not XP.

 

[Nil]

I'll look into that. I wouldn't mind another search program,
although there is little point to installing software on this
temporary computer.

I like Agent Ransack, which can search for file names and content, even
using regular expressions. It's more flexible than Windows Search. But
I was recently turned on to Everything, which searches only file names.
It maintains an index, and is blindingly fast. Most of my searches are
for file names, so Everything gets uses a lot more lately than Ransack.

http://www.voidtools.com/

 

[VanguardLH]

That can't be true, because the same search found, in my backup
partition, the same file with the same extension. I suspect because
this was a backup of winME and the fully qualified name was much
shorter, it displayed it. (For the benefit of newbie readers, WinME
doesn't have separate personas and separate sets of application data,
so the file name is shorter. (Or because Application Data in winME is
not a hidden directory. After all, it's everyone's application data,
so why bother to hide it, I guess.)

You actually have a backup program that uses .js as the extension for
its backup files?

The example you gave for the file path was:

C:\Doecuments and Setting\Administrator\Application
Data\Mozilla\Firefox\Profiles\nlnlnnll.default\sessionstore.js

That's not very long. Doesn't even come close to the old 256-character
DOS limit. That's only 113 characters long; however, I don't know what
was the actual account name under which you were searching (to know its
length) or how large the n's and l's expand for numbers and letters. Of
course, that path probably doesn't exist ("Doecuments" versus
"Documents" and "Setting" versus "Settings").

Looks like you already found your solution: enabling searching in
"system folders" (probably not what fixed your immediate problem) and
"showing hidden folders/files" (which is probably what let you see the
file). As mentioned (2nd paragraph of my reply, and I see Nil mentioned
it 19 minutes earlier), you have to use the Advanced setting to list
system and hidden objects. That Advanced isn't enabled by default (or
stays the same from its prior use) is one of the reasons that I don't
like Microsoft's search companion is that it defaults to OFF for the
advanced settings. You have to remember to enable advanced settings and
then elect to show system and hidden objects. Not needed with
FileLocator Lite. It finds everything (well, everything through the
system API for file objects but not if a rootkit is hiding files).

 

[VanguardLH]

I don't think that is accurate. It may true be for Vista and up, but
not XP.

It's an old "bug" (behavior change) that users complained about when
Windows XP showed up and users noticed files weren't getting found that
they knew existed, like seeing the file in a DOS shell (command prompt)
using the 'dir' command.

http://www.petri.co.il/windows_xp_search_bug.htm

The PersistentHandler registry entry defines the viewer (aka handler)
for that filetype. Method #2 is a fix to the file indexing which I
never enable (and expressly disable or check it's disabled after a fresh
install of Windows XP).

One of the reasons Agent Ransack (renamed to FileLocator Lite) and other
search tools became popular was they overcame the deficiences of the
"new" search companion that came in Windows XP. Searches that worked in
Windows 2000 stopped working in Windows XP.

 

[Nil]

It's an old "bug" (behavior change) that users complained about
when Windows XP showed up and users noticed files weren't getting
found that they knew existed, like seeing the file in a DOS shell
(command prompt) using the 'dir' command.

http://www.petri.co.il/windows_xp_search_bug.htm

This article is about finding text content in files. There may be a bug
with that function, but it doesn't apply to this thread, which is about
finding files by name. There is no bug about that, as far as I can
tell. I can generate a file with a name that is not associated with any
file type, and Windows search finds it with no problem.

The PersistentHandler registry entry defines the viewer (aka
handler) for that filetype. Method #2 is a fix to the file
indexing which I never enable (and expressly disable or check it's
disabled after a fresh install of Windows XP).

Me, too. One of the first things I do on a new XP install is turn
indexing all the way off.

 

[VanguardLH]

This article is about finding text content in files.

That was the intro. READ the article. It's about the persistent file
handler defined in the registry (and not having that definition). Deny
all you want but many Windows XP users have long known that the Windows
XP search companion won't find files because their content type isn't
known so search won't list them.

Yes, the OP wanted to find files by their name. Yeah, and? That
doesn't change how the search companion in Windows XP works.

Think about it: why does the search companion even look inside a text
file to look for a string when you are searching on the filename only?
You didn't specify a non-blank value for "Containing text" (i.e., you
left it empty). You only entered a non-blank value in "Search files or
folders named". Yet if you use a file monitor (I still have FileMon
SysInternals since if don't care for the merged version that includes
the process monitor) and start a search on just a filename, search
companion OPENS the file to look at its content despite it wasn't told
to look for anything inside the file. Say I do a search on *.txt files.
I filter the file monitor to watch for what happens on *.txt files. I
start the search. Sure enough, I see search companion is OPENing the
..txt files rather than just query the file system. Because I didn't
specify a string to search inside the text files, there is no Read
operation; however, an Open operation is not required on a file to find
it in a directory listing.

When I do the same search on *.txt files using FileLocator Lite (aka
Agent Ransack), it finds 2246 text files but not one of them had the
OPEN operation performed on it. There is a big difference between
querying the file system to get filenames and issuing an OPEN on each
found file.

Without a persistent handler (viewer) associated to a filetype, search
companion has no means of knowing the structure inside a file that it
WILL open during a search even is the "Containing text" option is empty.
Just because a file has no extension doesn't mean that it has no
structure. I'm sure if I dug around the registry that I'd find the
handler used for non-typed files (with no extension). I don't think
HKEY_CLASSES_ROOT\*\OpenWithList is what gets used unless search
companion simply defaults to using text mode to scan inside non-typed
files.

It's been around 8 years since I got Windows XP when I discovered the
search companion's deficiency. As I recall, the problem was described
as not having an appropriate "filter" component to let the search look
inside a file (even when you specifically did not enter a string to find
inside the found files). http://support.microsoft.com/kb/309173 may
have something to do with the problem because, as I also recall, I'd
search for strings in .html files that it couldn't find because they
happen to be inside a comment tag. Notice that it also mentions the
PersistentHandler registry data item that the prior article also
mentioned.

Yeah, you wouldn't expect a filename-only search to open files but
that's what the search included in Windows XP does. The KB article
mentions the addition of more filters (handlers) in an update but that
obviously doesn't cover all filetypes (by extension) which means there
are files out there that search companion won't understand the structure
of their content - which is only a problem because search companion
wants to open a file instead of just find it in a directory listing.

 

[philo]

Because starting with Windows XP and after, Microsoft changed the search
function to only list files for which it has a viewer.

Total BS

 

[John John MVP]

That was the intro. READ the article. It's about the persistent file
handler defined in the registry (and not having that definition). Deny
all you want but many Windows XP users have long known that the Windows
XP search companion won't find files because their content type isn't
known so search won't list them.

That is not true, the article that you point to only applies when
searching for text or strings within files, has absolutely nothing
whatsoever to do with file names or files with unknown extensions.

John

 

[micky]

+1
But OTOH, (and IIRC), it does skip over some system type or related files.
I'm not using it now, so I can't recall what it was missing. (I'm using
Agent Ransack and FileLocator Pro - which are MUCH better, and both show ALL
files in the search you specify).

Aren't a lot of these MS flaws because they have tailored their design
to people who know nothing about computers. "Don't let them see the
system files -- they're so stupid they'll delete them. We need to
hide other files too. Oh he said in Folder Options he wanted to see
them? So what, we're protecting him and he has to say it here too.
And for gosh sakes, don't call them directories. That's too confusing.
Call them folders because if he's a businessman, he has real folders
in his metal file cabinet and he knows what they are."

 

[micky]

This article is about finding text content in files. There may be a bug
with that function, but it doesn't apply to this thread, which is about
finding files by name. There is no bug about that, as far as I can
tell. I can generate a file with a name that is not associated with any
file type, and Windows search finds it with no problem.


Me, too. One of the first things I do on a new XP install is turn
indexing all the way off.

I tried it once and it slowed everything down. That's the problem
with it, right? I turned it off.

 

[micky]

You actually have a backup program that uses .js as the extension for
its backup files?

No, the opposite. I have a backup of almost every file in my laptop
harddrive, including one .js file.

The example you gave for the file path was:

C:\Doecuments and Setting\Administrator\Application
Data\Mozilla\Firefox\Profiles\nlnlnnll.default\sessionstore.js

That's not very long. Doesn't even come close to the old 256-character
DOS limit.

I see that you're right about that. I guess I jumped to the length
conclusion when I copied 3 of the files ending in .js to up to the
Firefox directory, so the file name no longer hard
Profiles\nlnlnnll.default in it, and those files showed up in the
Search results** but they disappeared from there by the next day.

**It's a good feature of Search that after its run it monitors and
displays matching new files, and probably undisplyays deleted files,
even without clicking on "search" again. I guess this time it
displayed those 3 files I copied before it checked if the directory
two levels above was hidden. When it did check, it stopped displaying
them. That doesn't sound very likely, little more likely than that
the file name was too long, but it seems to be what happened.

That's only 113 characters long; however, I don't know what
was the actual account name under which you were searching (to know its
length) or how large the n's and l's expand for numbers and letters. Of

They are one letter each, and the rest is exactly the same, except it
was the D: drive. You are right. It's definitely too short to be a
problem. I was grasping at straws.

course, that path probably doesn't exist ("Doecuments" versus
"Documents" and "Setting" versus "Settings").

Yes, those were misspellings. I still didn't see them until just now.

Looks like you already found your solution: enabling searching in
"system folders"

That I had to begin with.

(probably not what fixed your immediate problem) and
"showing hidden folders/files"

Yes, that was it.

(which is probably what let you see the
file). As mentioned (2nd paragraph of my reply, and I see Nil mentioned
it 19 minutes earlier), you have to use the Advanced setting to list
system and hidden objects. That Advanced isn't enabled by default (or
stays the same from its prior use)

Bummer. So I have to reset that every time? I wonder if that
accounts for other seraches that didn't work well.

is one of the reasons that I don't
like Microsoft's search companion is that it defaults to OFF for the
advanced settings. You have to remember to enable advanced settings and
then elect to show system and hidden objects. Not needed with
FileLocator Lite. It finds everything (well, everything through the
system API for file objects but not if a rootkit is hiding files).

Hopefully no rootkit to contend with.

Thanks.

 

[Nil]

That was the intro. READ the article. It's about the persistent
file handler defined in the registry (and not having that
definition). Deny all you want but many Windows XP users have
long known that the Windows XP search companion won't find files
because their content type isn't known so search won't list them.

I read the article before, but to give you the benefit of a doubt, I
read it again. The entire article is about finding content in files,
not about finding file names. In which paragraph do you see otherwise?

Sometimes being condescending can bite you on the ass.

Yes, the OP wanted to find files by their name. Yeah, and?

Yeah, and: you're changing the subject. Sometimes known as "shifting
the goalposts."

 

[VanguardLH]

Total BS

Read my reply which has Microsoft explain why it won't find files. Yep,
has to do with the lack of a PersistantHandler definition. Now you go
argue with Microsoft.