Everything doesn't find notepad, Vista

In alt.windows7.general, on Tue, 13 Oct 2015 09:50:36 -0500, VanguardLH
wrote:

Bob L wrote:

micky wrote:

... I opened Everything...
I only entered notepad and I got 14 objects, but none were the basic
notepad.exe!! When I finishedwriting notepad.exe, there were 9,
but two were notepad.exe.mui, one was prefetch, and 6 were long
names that start
C:\windows\winsxs\x86_microsoft-windows-notepad
...

Just a thought if one of your disks is FAT 32 then Everything will not
search these, it is NTFS only.

I'm glad you pointed that out. I do have a FAT32 partition and I
noticed its copy of notepad wasn't listed. I'm sorry to hear it
doesn't do FAT32, although I had it for Win98 and I'll probably use it
less and less.

http://www.voidtools.com/faq/#What_a...for_Everything
What are the system requirements for "Everything"?
"Everything" will run on Windows XP, Vista, Windows 7 and Windows 8
Indexing NTFS volumes requires the Everything service or running
"Everything" as administrator.

I'm 99% sure I'm running as administrator, and with all three HDDs
connected, it finds 616 thousand files. Does that mean indexing is
working.?

The OP never mentioned under what type of account he was logged in when
running Everything. Without running as a service or ran under an
admin-level Windows account, the Troubleshooting section says the result
list would be empty or just a list of drives.

I certainly don't have that. Earlier in the thread I mentioned the 9
files I got in C: with the name notepad.exe. Six had the long path name
with SXS in it, two were prefetch, etc. Oh, you point that out in the
next sentence.

Since the OP mentions
other files are found (just not the one he was expecting to be
included), doesn't sound like an NTFS problem.

Right.

But I found something else interesting. First I checked Search /
Match Path, but then I saw I didnt' have to check that.

I just started entering the path.

Because you guys have 7 and not Vista, you may not get these exact
results, but I'll bet they are similar.

It's only going to consider the C: drive:
c:\windows gives 74 thousand files
c:\windows\s gives 19 thousand
c:\windows\sy gives 14 thousand
c:\windows\sys gives the same, 14,935
c:\windows\syst gives 14,935
c:\windows\system gives 14,935
c:\windows\system3 gives 14,933, two fewer
c:\windows\system32\ gives 14,932, one fewer
c:\windows\system32\n gives 11 6 subdirectories, one of them
networklinks, which has its own subdir, Icons, which has 4 files and its
own subdir StockIcons, which has 12 .bin files, none of which are
listed. Other subdirs of
system 32 that start with N are nb-NO, NDF, and nl-NL,

nb-NO has 8 .dll.mui files, none of which are listed.
NDF has no files.
nl-NL has 8 .dll.mui files, none of which are listed.

Forgetting subdirs now, there are 190 files that begin with N and are in
system32 proper, not a subdirectory, and NONE are listed.

So I get rid of the N at the end of the search line and go back to
c:\windows\system32, and look at the 14,932 files which are in
alphabetical order, and there are NO files that start with N that are
listed there either, only files that start with n that are in
subdirectories of it. Where are the 190 files, including notepad.exe?

In alt.windows7.general, on Tue, 13 Oct 2015 01:27:50 -0500, VanguardLH
wrote:

Char Jackson wrote:

micky wrote:

All of this is moot now, I think. Other replies explained this part:

If I select Executable, it lowers the number from 32 (now that the
other partitions are connected) to 25, ALL of which are exactly
notepad.exe, in lower or upper case, including the path
d:\windows\system32 and the same path in two other partitions.

Why do you have a d:\Windows\system32 folder and why don't you think the
copy of Notepad.exe in there is the one you're using?

I'm not saying you're wrong; I'm just curious.

After starting notepad.exe, right-clicking on the process in Task
Manager's Process tab will show the path to the process' executable.

While the old pathing default looked for an executable in the current
(working) directory and, if not found there, would use the PATH
environment variable to search those paths, in the order listed, for the
executable, there is also the AppPaths registry entry listing where to
find programs.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Cur rentVersion\App Paths

Each subkey is the filename of the executable. The "(Default)" named
data item's value is the path to the executable.

I looked in my Win7 setup but notepad.exe is not in the registry
AppPaths list. Windows must be using the old pathing default to find
the executable. The system32 folder should be already added to the
[system] PATH environment variable.

As to why there are so many instances of notepad.exe, I already
explained WinSXS (Windows Side-By-Side repositories) in my reply to
Ross. It is unlikely any app will use those instances of notepad.exe
but that doesn't stop authors from programming their installers to dump
ancilliary albeit superfluous files into their repository.

Your reply cues that micky might have multiple images of Windows on
different disks and why Everything finds so many copies of notepad.exe.
Could be D: is the drive letter assigned to the currently running
instance of Windows and C: is another Windows image (not currently
loaded). Or maybe the OP cloned the C: drive (from which Windows is
currently loaded) to the D: drive which would mean there would be
duplicates of notepad.exe on the D: drive.

I answer this below, but my other answer to another post of yours is far
more important. You can just about skip this one, except maybe for
background. .

C: is the Vista partition, that I am actually running in. It's the only
partition on the only internal drive.

The other partitions are in a USB dock. They were backup partitions
for my recently failed XP computer. D: was the Windows partition in
that computer, and the external drive partitions which were clones of XP
had letters H, K, and L; but a) the letters assigned by Vista seem
unrelated to the letters they used to have, I havent' tried to assign
letters via Vista b) the drives are in the dock in reverse order from
what they used to be. Because I'm not depending on drive letter now.
I'm only using the drives to copy over selected files and I'm going by
partition label.

When the power to the dock is removed, there is only the C: drive, and
notepad is still there, in c:\windows\system32\notepad.exe and it
works, and it's the one that is being used, as shown by the Process tab
of Task Manager.

But even if it's not the one that's being used, it's there and should
show up in Search Everything

micky wrote:

I had never done that anyhow. I think our needs are pretty different,
but I'm still going to look at Ransack. Thanks

But I still have to solve this problem.

I had a theory, before I started checking, that the problem
is related to "hard links". What I find odd, is my favorite
Microsoft utility "nfi.exe" is missing stuff in the same
way that Everything does. (Or rather, nfi didn't print as
much info as it should have.)

First of all, tools that scan directories by traversal (Ransack),
don't miss stuff. I didn't prepare a list from Ransack, and
instead, I'll show the result from Linux. Which also works by
traversal. And also has the neat feature of providing "inode number"
and "ref count". NTFS doesn't have inode number, NTFS has file number.
But the Linux NTFS driver is designed to try to fill in file system
metadata (sorta POSIX compliant), so Linux applications will not fail
or trip up. So they "substitute" information as best they can. And it
looks like the file number is used as the starting inode of a file.

The letter "R" is the column for reference count, the supposed number
of items referring to the same set of data clusters.

Inode R Size

25694 -rw 5 mint mint 10752 Sep 30 2013 ./Windows/System32/en-US/notepad.exe.mui
25694 -rw 5 mint mint 10752 Sep 30 2013 ./Windows/SysWOW64/en-US/notepad.exe.mui
25694 -rw 5 mint mint 10752 Sep 30 2013 ./Windows/WinSxS/x86_microsoft-windows-notepad.resources_31bf3856ad364e35_6.3.9600.16384_ en-us_b2859c98ea93b4ce/notepad.exe.mui
25694 -rw 5 mint mint 10752 Sep 30 2013 ./Windows/WinSxS/amd64_microsoft-windows-notepad.resources_31bf3856ad364e35_6.3.9600.16384_ en-us_0ea4381ca2f12604/notepad.exe.mui
25695 -rw 3 mint mint 10752 Sep 30 2013 ./Windows/en-US/notepad.exe.mui
25695 -rw 3 mint mint 10752 Sep 30 2013 ./Windows/WinSxS/amd64_microsoft-windows-notepadwin.resources_31bf3856ad364e35_6.3.9600.163 84_en-us_89e731799f1056f0/notepad.exe.mui
35801 -rw 1 mint mint 22006 Mar 10 2015 ./Windows/WinSxS/wow64_microsoft-windows-notepad_31bf3856ad364e35_6.3.9600.16384_none_6a2d9 7d8785783e2/notepad.exe
84241 -rw 1 mint mint 25382 Mar 10 2015 ./Windows/WinSxS/amd64_microsoft-windows-notepadwin_31bf3856ad364e35_6.3.9600.16384_none_33 882ce9cf04143d/notepad.exe
84243 -rw 1 mint mint 25382 Mar 10 2015 ./Windows/WinSxS/amd64_microsoft-windows-notepad_31bf3856ad364e35_6.3.9600.16384_none_5fd8e d8643f6c1e7/notepad.exe
92787 -rw 1 mint mint 6514 Jul 22 02:01 ./Users/username/AppData/Local/Microsoft/Windows/WER/ReportArchive/AppHang_notepad.exe_fcf353569f22dff1f2ea19f3afcc69 3582667794_012e98cd_0a71b7fe/Report.wer
125549 -rw 2 mint mint 221184 Oct 29 2014 ./Windows/notepad.exe
125549 -rw 2 mint mint 221184 Oct 29 2014 ./Windows/WinSxS/amd64_microsoft-windows-notepadwin_31bf3856ad364e35_6.3.9600.17415_none_33 d4c7c5ceca80c5/notepad.exe
125551 -rw 2 mint mint 212992 Oct 29 2014 ./Windows/SysWOW64/notepad.exe
125551 -rw 2 mint mint 212992 Oct 29 2014 ./Windows/WinSxS/wow64_microsoft-windows-notepad_31bf3856ad364e35_6.3.9600.17415_none_6a7a3 2b4781df06a/notepad.exe
125552 -rw 2 mint mint 221184 Oct 29 2014 ./Windows/System32/notepad.exe
125552 -rw 2 mint mint 221184 Oct 29 2014 ./Windows/WinSxS/amd64_microsoft-windows-notepad_31bf3856ad364e35_6.3.9600.17415_none_60258 86243bd2e6f/notepad.exe

Everything Export

"AppHang_notepad.exe_fcf353569f22dff1f2ea19f3afcc6 93582667794_012e98cd_0a71b7fe","C:\Users\username\ AppData\Local\Microsoft\Windows\WER\ReportArchive" ,"","7/21/2015 10:01 PM"
"Report.wer","C:\Users\username\AppData\Local\Micr osoft\Windows\WER\ReportArchive\AppHang_notepad.ex e_fcf353569f22dff1f2ea19f3afcc693582667794_012e98c d_0a71b7fe","6514","7/21/2015 10:01 PM"
"notepad.exe","C:\Windows\WinSxS\amd64_microso ft-windows-notepad_31bf3856ad364e35_6.3.9600.16384_none_5fd8e d8643f6c1e7","25382","3/10/2015 12:45 AM"
"notepad.exe","C:\Windows\WinSxS\amd64_microso ft-windows-notepad_31bf3856ad364e35_6.3.9600.17415_none_60258 86243bd2e6f","221184","10/28/2014 10:16 PM"
"notepad.exe.mui","C:\Windows\WinSxS\amd64_microso ft-windows-notepadwin.resources_31bf3856ad364e35_6.3.9600.163 84_en-us_89e731799f1056f0","10752","9/29/2013 11:48 PM"
"notepad.exe","C:\Windows\WinSxS\amd64_microso ft-windows-notepadwin_31bf3856ad364e35_6.3.9600.16384_none_33 882ce9cf04143d","25382","3/10/2015 12:45 AM"
"notepad.exe","C:\Windows\WinSxS\amd64_microso ft-windows-notepadwin_31bf3856ad364e35_6.3.9600.17415_none_33 d4c7c5ceca80c5","221184","10/28/2014 10:16 PM"
"notepad.exe","C:\Windows\WinSxS\wow64_microso ft-windows-notepad_31bf3856ad364e35_6.3.9600.16384_none_6a2d9 7d8785783e2","22006","3/10/2015 1:08 AM"
"notepad.exe","C:\Windows\WinSxS\wow64_microso ft-windows-notepad_31bf3856ad364e35_6.3.9600.17415_none_6a7a3 2b4781df06a","212992","10/28/2014 9:37 PM"
"notepad.exe.mui","C:\Windows\WinSxS\x86_micro soft-windows-notepad.resources_31bf3856ad364e35_6.3.9600.16384_ en-us_b2859c98ea93b4ce","10752","9/29/2013 11:47 PM"

In the Linux output, there are four "notepad.exe.mui" having the same
file number (25694) and size (10752 bytes). Everything only has
one instance like that. Linux gets the ref count wrong (5), when there
are only four items having the same inode. Those would be hard linked
files.

In the Linux output, there are two "notepad.exe.mui" having the same
file number (25695) and size (10752 bytes). Everything only has
one instance like that. Linux gets the ref count wrong (3), when there
are only two items having the same inode. Those would be hard linked
files.

And the surprise for me, was the output from NFI was as thin
as the output of Everything. But the results aren't exactly
the same either. These are the lines that had notepad.exe in them.

\Windows\System32\en-US\notepad.exe.mui
\Windows\en-US\notepad.exe.mui
\Windows\WinSxS\wow64_microsoft-windows-notepad_31bf3856ad364e35_6.3.9600.16384_none_6a2d9 7d8785783e2\notepad.exe
\Windows\WinSxS\amd64_microsoft-windows-notepadwin_31bf3856ad364e35_6.3.9600.16384_none_33 882ce9cf04143d\notepad.exe
\Windows\WinSxS\amd64_microsoft-windows-notepad_31bf3856ad364e35_6.3.9600.16384_none_5fd8e d8643f6c1e7\notepad.exe
\Users\username\AppData\Local\Microsoft\Windows\WE R\ReportArchive\AppHang_notepad.exe_fcf353569f22df f1f2ea19f3afcc693582667794_012e98cd_0a71b7fe
\Users\username\AppData\Local\Microsoft\Windows\WE R\ReportArchive\AppHang_notepad.exe_fcf353569f22df f1f2ea19f3afcc693582667794_012e98cd_0a71b7fe\Repor t.wer
\Windows\notepad.exe
\Windows\SysWOW64\notepad.exe
\Windows\WinSxS\amd64_microsoft-windows-notepad_31bf3856ad364e35_6.3.9600.17415_none_60258 86243bd2e6f\notepad.exe

So it would appear that the first instance of a file (pointer) is
picked up by $MFT based tools. They cannot see all four of the
notepad.exe.mui for example. I was hoping NFI (a tool which lists
the sectors taken up by a file), would show all the file pointers,
but it doesn't. Perhaps it asks for items by "file number".

Now, if I show the full output for file 25694 in NFI, you
can see there is room to store the pointers. And you can
also see how Linux got the wrong reference count. There are
five apparent slots to hold pointers. Linux "counted to 5"
like it was supposed to. No idea how there are five, when
Windows is only using four of them.

File 25694
\Windows\System32\en-US\notepad.exe.mui
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 33984-34007 (0x84c0-0x84d7)

File 25695
\Windows\en-US\notepad.exe.mui
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 8539200-8539223 (0x824c40-0x824c57)

So my guess is, Everything asks for file number, finds
the first $FILE_NAME and that is all it records. It
doesn't bother to add the other $FILE_NAME entries
as official filenames.

And this file from NFI, was an example of a file having only
a single pointer. So if a file has a single pointer, there
is one $FILE_NAME. If a file has two pointers (is hard linked)
there are three entries (c.f. 25695 example above).

File 92787
\Users\username\AppData\Local\Microsoft\Windows\WE R\ReportArchive\AppHang_notepad.exe_fcf353569f22df f1f2ea19f3afcc693582667794_012e98cd_0a71b7fe\Repor t.wer
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$DATA (nonresident)
logical sectors 36099024-36099031 (0x226d3d0-0x226d3d7)

While it's easy to understand the mechanism by which
Everything missed this, it's harder to understand how
the Everything developer ("still developing the App")
doesn't notice this has happened.

There's no way to fix this right now, short of using Ransack...
"Slow and steady, wins the race."

Paul

Paul wrote:
micky wrote:

I had never done that anyhow. I think our needs are pretty different,
but I'm still going to look at Ransack. Thanks

But I still have to solve this problem.

Forgot one other detail. How to do the Linux listings...

This separates directories from files, and the "i" option
helps to include the inode number and reference count in
the "/bin/ls" output. I go away and make coffee while
this is running.

cd /media/mint/WIN81
find . -type d -exec ls -ali -1 -d {} + ~/directories.txt
find . -type f -exec ls -ali -1 {} + ~/filelist.txt

Paul

On Tue, 13 Oct 2015 20:25:30 -0400, Paul wrote:

micky wrote:

I had never done that anyhow. I think our needs are pretty different,
but I'm still going to look at Ransack. Thanks

But I still have to solve this problem.

I had a theory, before I started checking, that the problem
is related to "hard links". What I find odd, is my favorite
Microsoft utility "nfi.exe" is missing stuff in the same
way that Everything does. (Or rather, nfi didn't print as
much info as it should have.)

First of all, tools that scan directories by traversal (Ransack),
don't miss stuff.

OK, so maybe micky will configure Everything to scan his C:\Windows folder
instead of simply letting it detect files and changes based on USN
journaling. If folder scanners don't miss files, a premise with which I
agree, then that will solve the immediate problem. It won't, however, answer
the underlying question.

In Everything, Tools, Options, Folders, add C:\Windows and hit Update Now.

While it's easy to understand the mechanism by which
Everything missed this, it's harder to understand how
the Everything developer ("still developing the App")
doesn't notice this has happened.

He may not have noticed it because it doesn't happen to everyone. For
example, I have Everything installed on two Win 7 PCs and a Win 8 PC.
Everything finds Notepad.exe just fine on each of my three PCs.

There's no way to fix this right now, short of using Ransack...

See above. Simply configure Everything to scan that folder.


--

Char Jackson

Char Jackson wrote:
On Tue, 13 Oct 2015 20:25:30 -0400, Paul wrote:

micky wrote:

I had never done that anyhow. I think our needs are pretty different,
but I'm still going to look at Ransack. Thanks

But I still have to solve this problem.
I had a theory, before I started checking, that the problem
is related to "hard links". What I find odd, is my favorite
Microsoft utility "nfi.exe" is missing stuff in the same
way that Everything does. (Or rather, nfi didn't print as
much info as it should have.)

First of all, tools that scan directories by traversal (Ransack),
don't miss stuff.

OK, so maybe micky will configure Everything to scan his C:\Windows folder
instead of simply letting it detect files and changes based on USN
journaling. If folder scanners don't miss files, a premise with which I
agree, then that will solve the immediate problem. It won't, however, answer
the underlying question.

In Everything, Tools, Options, Folders, add C:\Windows and hit Update Now.

While it's easy to understand the mechanism by which
Everything missed this, it's harder to understand how
the Everything developer ("still developing the App")
doesn't notice this has happened.

He may not have noticed it because it doesn't happen to everyone. For
example, I have Everything installed on two Win 7 PCs and a Win 8 PC.
Everything finds Notepad.exe just fine on each of my three PCs.

There's no way to fix this right now, short of using Ransack...

See above. Simply configure Everything to scan that folder.

I see I've made a mistake.

I was testing version "Everything 1.3.4.686", because it appears
at the top of the web page, and with the level of magnification I
had set for the page (I've been to the site before), I completely
missed the version below it. Instead of putting the most recent
version of the tool at the top, they put it below.

So I tested "Everything 1.4.0.705b Beta" on the Win8 machine again.

"Name","Path","Size","Date Modified"

"notepad.exe.mui","C:\Windows\System32\en-US","10752","9/29/2013 11:47 PM"
"notepad.exe.mui","C:\Windows\SysWOW64\en-US","10752","9/29/2013 11:47 PM"
"notepad.exe.mui","C:\Windows\WinSxS\amd64_microso ft-windows-notepad.resources_31bf3856ad364e35_6.3.9600.16384_ en-us_0ea4381ca2f12604","10752","9/29/2013 11:47 PM"
"notepad.exe.mui","C:\Windows\WinSxS\x86_micro soft-windows-notepad.resources_31bf3856ad364e35_6.3.9600.16384_ en-us_b2859c98ea93b4ce","10752","9/29/2013 11:47 PM"

"notepad.exe.mui","C:\Windows\en-US","10752","9/29/2013 11:48 PM"
"notepad.exe.mui","C:\Windows\WinSxS\amd64_microso ft-windows-notepadwin.resources_31bf3856ad364e35_6.3.9600.163 84_en-us_89e731799f1056f0","10752","9/29/2013 11:48 PM"

The beta version appears to be picking up the hard link files.
I recommend a retest using the beta bersion.

Paul

On Tue, 13 Oct 2015 23:20:12 -0400, Paul wrote:

Char Jackson wrote:
On Tue, 13 Oct 2015 20:25:30 -0400, Paul wrote:

micky wrote:

I had never done that anyhow. I think our needs are pretty different,
but I'm still going to look at Ransack. Thanks

But I still have to solve this problem.
I had a theory, before I started checking, that the problem
is related to "hard links". What I find odd, is my favorite
Microsoft utility "nfi.exe" is missing stuff in the same
way that Everything does. (Or rather, nfi didn't print as
much info as it should have.)

First of all, tools that scan directories by traversal (Ransack),
don't miss stuff.

OK, so maybe micky will configure Everything to scan his C:\Windows folder
instead of simply letting it detect files and changes based on USN
journaling. If folder scanners don't miss files, a premise with which I
agree, then that will solve the immediate problem. It won't, however, answer
the underlying question.

In Everything, Tools, Options, Folders, add C:\Windows and hit Update Now.

While it's easy to understand the mechanism by which
Everything missed this, it's harder to understand how
the Everything developer ("still developing the App")
doesn't notice this has happened.

He may not have noticed it because it doesn't happen to everyone. For
example, I have Everything installed on two Win 7 PCs and a Win 8 PC.
Everything finds Notepad.exe just fine on each of my three PCs.

There's no way to fix this right now, short of using Ransack...

See above. Simply configure Everything to scan that folder.

I see I've made a mistake.

I was testing version "Everything 1.3.4.686", because it appears
at the top of the web page, and with the level of magnification I
had set for the page (I've been to the site before), I completely
missed the version below it. Instead of putting the most recent
version of the tool at the top, they put it below.

I use "Everything 1.3.4.686".


So I tested "Everything 1.4.0.705b Beta" on the Win8 machine again.

"Name","Path","Size","Date Modified"

"notepad.exe.mui","C:\Windows\System32\en-US","10752","9/29/2013 11:47 PM"
"notepad.exe.mui","C:\Windows\SysWOW64\en-US","10752","9/29/2013 11:47 PM"
"notepad.exe.mui","C:\Windows\WinSxS\amd64_micros oft-windows-notepad.resources_31bf3856ad364e35_6.3.9600.16384_ en-us_0ea4381ca2f12604","10752","9/29/2013 11:47 PM"
"notepad.exe.mui","C:\Windows\WinSxS\x86_microsof t-windows-notepad.resources_31bf3856ad364e35_6.3.9600.16384_ en-us_b2859c98ea93b4ce","10752","9/29/2013 11:47 PM"

"notepad.exe.mui","C:\Windows\en-US","10752","9/29/2013 11:48 PM"
"notepad.exe.mui","C:\Windows\WinSxS\amd64_micros oft-windows-notepadwin.resources_31bf3856ad364e35_6.3.9600.163 84_en-us_89e731799f1056f0","10752","9/29/2013 11:48 PM"

The beta version appears to be picking up the hard link files.

But still not picking up either of the copies of notepad.exe?? On my PCs, it
picks up the version in C:\Windows\System32 (189KB) and the version in
C:\Windows\SysWOW64 (176KB), in addition to the other non-exe copies.

I recommend a retest using the beta bersion.

"Everything 1.3.4.686" works fine here.

--

Char Jackson

Char Jackson wrote:
On Tue, 13 Oct 2015 23:20:12 -0400, Paul wrote:

So I tested "Everything 1.4.0.705b Beta" on the Win8 machine again.

"Name","Path","Size","Date Modified"

"notepad.exe.mui","C:\Windows\System32\en-US","10752","9/29/2013 11:47 PM"
"notepad.exe.mui","C:\Windows\SysWOW64\en-US","10752","9/29/2013 11:47 PM"
"notepad.exe.mui","C:\Windows\WinSxS\amd64_microso ft-windows-notepad.resources_31bf3856ad364e35_6.3.9600.16384_ en-us_0ea4381ca2f12604","10752","9/29/2013 11:47 PM"
"notepad.exe.mui","C:\Windows\WinSxS\x86_micro soft-windows-notepad.resources_31bf3856ad364e35_6.3.9600.16384_ en-us_b2859c98ea93b4ce","10752","9/29/2013 11:47 PM"

"notepad.exe.mui","C:\Windows\en-US","10752","9/29/2013 11:48 PM"
"notepad.exe.mui","C:\Windows\WinSxS\amd64_microso ft-windows-notepadwin.resources_31bf3856ad364e35_6.3.9600.163 84_en-us_89e731799f1056f0","10752","9/29/2013 11:48 PM"

The beta version appears to be picking up the hard link files.

But still not picking up either of the copies of notepad.exe?? On my PCs, it
picks up the version in C:\Windows\System32 (189KB) and the version in
C:\Windows\SysWOW64 (176KB), in addition to the other non-exe copies.

I recommend a retest using the beta bersion.

"Everything 1.3.4.686" works fine here.


I picked those specific six files, to show that the 1.4.0.705b Beta
picks up hard links, while the 1.3.4.686 did not.

I didn't feel it was worth repeating the entire list.

Paul

On Wed, 14 Oct 2015 01:53:41 -0400, Paul wrote:

Char Jackson wrote:
On Tue, 13 Oct 2015 23:20:12 -0400, Paul wrote:

So I tested "Everything 1.4.0.705b Beta" on the Win8 machine again.

"Name","Path","Size","Date Modified"

"notepad.exe.mui","C:\Windows\System32\en-US","10752","9/29/2013 11:47 PM"
"notepad.exe.mui","C:\Windows\SysWOW64\en-US","10752","9/29/2013 11:47 PM"
"notepad.exe.mui","C:\Windows\WinSxS\amd64_microso ft-windows-notepad.resources_31bf3856ad364e35_6.3.9600.16384_ en-us_0ea4381ca2f12604","10752","9/29/2013 11:47 PM"
"notepad.exe.mui","C:\Windows\WinSxS\x86_micro soft-windows-notepad.resources_31bf3856ad364e35_6.3.9600.16384_ en-us_b2859c98ea93b4ce","10752","9/29/2013 11:47 PM"

"notepad.exe.mui","C:\Windows\en-US","10752","9/29/2013 11:48 PM"
"notepad.exe.mui","C:\Windows\WinSxS\amd64_microso ft-windows-notepadwin.resources_31bf3856ad364e35_6.3.9600.163 84_en-us_89e731799f1056f0","10752","9/29/2013 11:48 PM"

The beta version appears to be picking up the hard link files.

But still not picking up either of the copies of notepad.exe?? On my PCs, it
picks up the version in C:\Windows\System32 (189KB) and the version in
C:\Windows\SysWOW64 (176KB), in addition to the other non-exe copies.

I recommend a retest using the beta bersion.

"Everything 1.3.4.686" works fine here.


I picked those specific six files, to show that the 1.4.0.705b Beta
picks up hard links, while the 1.3.4.686 did not.

I didn't feel it was worth repeating the entire list.

OK, I thought the OP was complaining about not finding any instances of
notepad.exe in C:\Windows, so that was my focus. I wasn't concerned with
anything else.

--

Char Jackson

In article , (VanguardLH) wrote:

But you do NOT have a sig - because you do NOT include a sigdash
line.

If your unidentified Usenet client does not automatically prefix the
sigdash line ("-- \n") then you will need to add it as the first
line of
your signature text.

Fair enough. Is this better?

--
Regards
John ) Remove the obvious to reply...

John K.Eason wrote:
In article , (VanguardLH) wrote:

But you do NOT have a sig - because you do NOT include a sigdash
line.

If your unidentified Usenet client does not automatically prefix the
sigdash line ("-- \n") then you will need to add it as the first
line of
your signature text.

Fair enough. Is this better?

--
Regards
John ) Remove the obvious to reply...

When I click "Reply" here, the .sig is not removed.

There should be a space character, after the --

Paul

David E. Ross wrote:

VanguardLH wrote:

John K.Eason wrote:

I specifically keep the sig to a couple of lines

Regards
John ) Remove the obvious to reply...

But you do NOT have a sig - because you do NOT include a sigdash line.

If your unidentified Usenet client does not automatically prefix the
sigdash line ("-- \n") then you will need to add it as the first line of
your signature text.

Per RFC 3676, a signature block begins with dash-dash-space on a line by
itself. Newsgroup applications are supposed to strip away that line amd
anything after it when quoting a prior message in a reply. See my
signature block below for an example.

I did not know that this was documented in an RFC. I thought it was a
Usenet de facto standard. Thanks for the update.

The page number (9) shown in the RFC's TOC is wrong. Page 8 has the
description in section 4.3, which says:

4.3. Usenet Signature Convention

There is a long-standing convention in Usenet news which also
commonly appears in Internet mail of using "-- " as the separator
line between the body and the signature of a message. When
generating a Format=Flowed message containing a Usenet-style
separator before the signature, the separator line is sent as-is.
This is a special case; an (optionally quoted or quoted and stuffed)
line consisting of DASH DASH SP is neither fixed nor flowed.

Generating agents MUST NOT end a paragraph with such a signature
line.

A receiving agent needs to test for a signature line both before the
test for a quoted line (see Section 4.5) and also after logically
counting and deleting quote marks and stuffing (see Section 4.4) from
a quoted line.

As I recall, some versions of Forte Agent did not automatically prepend
the sigdash line to the signature block. Those users had to add the
sigdash line as the first line of their signature block. John's client
doesn't identify itself (or John configured it to not identify itself)
so no idea what he needs to configure in his client to ensure the
sigdash line is included as part of his signature block.

John K.Eason wrote:

VanguardLH wrote:

But you do NOT have a sig - because you do NOT include a sigdash
line.

If your unidentified Usenet client does not automatically prefix the
sigdash line ("-- \n") then you will need to add it as the first
line of
your signature text.

Fair enough. Is this better?

Close but missing the trailing space character. Below the examples used
a leading space character so clients don't interpret the lines as
sigdash delimiters, so ignore the leading space:

--
(dash dash newline)

The de facto sigdash line is:

--
(dash dash SPACE newline)

Many clients are flexible in their interpretation of a sigdash line.
Outlook Express, for example, for MANY years used the first form.
Microsoft was clueless to Usenet for a long time, plus major versions of
Outlook Express were distributed only with Internet Explorer, so Outlook
Express did not often receive functional changes. As a consequence of
the number of OE users in Usenet and their client missing the trailing
space character in the sigdash line, most NNTP client added a test on
both formats. That did NOT mean the non-spaced version was a de facto
standard. It only meant that other clients had to accomodate
Microsoft's screwup due to the volume of users using the bad client (and
it got much worse after version 14 when Microsoft removed the code to
properly indent quoted content in replies).

Just add a trailing space onto your sigdash line to ensure that it
matches the de facto Usenet standard. David noted an RFC where it is
mentioned as a standard.

If I relied on Everything to index all files, I would also be perturbed
that Everything wasn't finding *everything*. It is an indexer tool so
maybe, like with the Windows file indexer, you have to define where the
indexer will look to index those files.

While the Windows and other indexing tools also look inside the files so
you can search on that content (i.e., you're looking for some content
and not for just files), Everything only indexes the filenames. From
its description, it is supposed to index all filenames.

There was a new build on Oct 15, 2015, so maybe the new version has bug
fixes that address your problem (well, it's problem). Alas, from what I
see under the Changelog tab at:

http://www.softpedia.com/progChangel...og-114264.html

none of the changes look to address the problem you noted. That is why
I mentioned discussing the defect in their forums (assuming the author
monitor those to address bugs with his software); else, you could use
his contact page at http://www.voidtools.com/contact/. If the problem
is a defect in the program rather than in its configuration, the author
might know about the bug unless someone reports it to him.

micky wrote on 10/13/2015 6:15 PM:

But even if it's not the one that's being used, it's there and should
show up in Search Everything

I asked on their forum and they suggested using the latest beta version
which does find all occurrences of notepad.exe.

http://www.voidtools.com/forum/viewtopic.php?f=2&t=5159&hilit=1.4.0.705b

http://www.voidtools.com/Everything-1.4.0.705b.x86-Setup.exe
http://www.voidtools.com/Everything-1.4.0.705b.x64-Setup.exe