Bug list for 1.2.1.371

[David]

• Empty volumes will not be included.
  • Status: Fixed for next release.
    Cause: Root folder is unintentionally excluded when no folders or files exists.
    Solution: Make sure there is at least one folder or file exists before indexing.
• Search Everything... from drives searches for "c:"".
  • Status: Fixed for next release.
    Cause: CommandLineToArgvW converting the trailing \ into a "
    Solution: http://forum.voidtools.com/viewtopic.php?f=5&t=6.
• Right clicking a folder or file in "Everything" crashes.
  • Status: Fixed for next release.
    Cause: shell context menu extensions not checking buffer sizes.
    Solution: Remove conflicting context menus or replace Everything.exe with http://www.voidtools.com/Everything-1.2.1.375b.zip .
• Update monitor fails
  • Status: Fixed for next release.
    Cause: Old monitoring events being processed after monitoring is stopped (caused by suspending computer).
    Solution: Restart "Everything" .
• no_taskbar_notification_icon ini option does not work.
  • Status: Fixed for next release.

[tworoom]

Search Everything... from drives searches for "Computer"".

"::{20D04FE0-3AEA-1069-A2D8-08002B30309D}" was shown but nothing can be searched

[yusufcandan]

Hi, thank you for this sw.

I want to report a bug. ES 1.2.1.371 does not indexes everthing. for instace I have 2 iasdatastore.dll file bur it shows only one of them. See screenshot. https://docs.google.com/leaf?id=0B-E6UE ... ZjNj&hl=en
I am sure it is not coused from being tha same name since when I copied the file which is not listed in ES to my desktop it appears in the search list. Moreover when I indexed my PC with another seach tool i.e. instant file find 1.6.1 it indexes 357000 files whereas ES 331000. Some files are missing in ES. I have double check every settings hovever the result is the same.

Thanks in advance.

[therube]

Definitely a strange one.

Initial thought was that it was a link (reparse point, symbolic link, junction, mount point), but it is not.
Then I thought some extremely long path/name, but that too is not it.

Then the naming is strange too. What appears to be a truncated name/path, but it is not. And the little old fact that there are 6700+ directories in the winsxs folder. (I counted them by hand so I may be off by a few .)

So now thinking that they are some kind of virtual data structure?

Would be interesting to understand this one.

What is the WINSXS directory in Windows 2008 and Windows Vista and why is it so large?

The WinSxS folder is the only location that the component is found on the system, all other instances of the files that you see on the system are “projected” by hard linking from the component store. Let me repeat that last point – there is only one instance (or full data copy) of each version of each file in the OS, and that instance is located in the WinSxS folder.

all other instances of the files that you see on the system are “projected” by hard linking from the component store

But this "hard linking" again must be some sort of virtual structure (?) as it is not a typical (even though none are in Windows) "link"?

[therube]

Interesting.

My E: partition (where I have Windows 7 installed), I created as 18 GB in size.
Properties on E: show 13 GB used, 5 GB free.

If I check usage using TreeSize Free, it shows E: to be using 16.1 GB with winxss taking up 4.5 GB of that total. So its representation is not accurate.

(5 GB of my used space is taken by pagefile.sys, 3 GB & hiberfil.sys, 2 GB. Otherwise other then the OS itself, there is virtually nothing of "mine" on E:.)

[therube]

"(Note: hardlinking of files is only an optimization - there are times when files must be projected by copying them.)

Using "dir /s" to compute the size of the winsxs directory will report every file and its size. Unfortunately, "dir" doesn't know how to deal with hard links, so it reports the total file size by summing the size of each name, not summing the size of the used disk space. This isn't a bug in dir, per-se. In NTFS, there is no such thing as the "first" link to a file, so there's no way to determine whether or not a file's size should be included in a scan."
http://blog.tiensivu.com/aaron/archives ... 32008.html


"Fsutil: hardlink

A hard link is a directory entry for a file. Every file can be considered to have at least one hard link. On NTFS volumes, each file can have multiple hard links, and thus a single file can appear in many directories (or even in the same directory with different names). Because all of the links reference the same file, programs can open any of the links and modify the file. A file is deleted from the file system only after all links to it have been deleted. After you create a hard link, programs can use it like any other file name."
http://www.microsoft.com/resources/docu ... dlink.mspx



"Once two files are linked together, you cannot determine which is the original file and which is the copy. This is because both file records will point to the same data on disk, and the pointer is a one-way link. The only information you can get about a linked file is the link count for that file, and the file index number, which is a 64-bit value that uniquely identifies that file on that volume. "
http://support.microsoft.com/kb/106166

"Hard link uses the same MFT entry as the original file. Adding a hard link creates a new name attribute and increases the hard link count (for a newly created file this count equals to one). Deleting a hard link removes the appropriate name and decreases the hard link count. When the count goes to zero, the system deletes the file, freeing up its allocated disk space and releasing its MFT record. All the name attributes are independent, so deleting, moving, or renaming the file don't affect other hard links. "
http://www.flexhex.com/docs/articles/hard-links.phtml

^
|
And with a link (& a "hard" link being what I would typically consider an UNIX link <ln>) it would be expected that Everything would only find one instance of the file. But what is not expected is that "junction" like utilities do not see these "hard links" - unless they are not made to see them, but only other types of links?


(Heh. And what was this thread about, Bug list for 1.2.1.371? Sorry about that.)

[therube]

And finally, proof in the pudding:




Had to install Link Shell Extension to be able to view this.
(I dislike installing programs, much less shell extensions. Anyhow, I've used this one in the past, but not on the particular computer I am now on. I hate that MS gives no, or only a terrible interface into some of its structures. I saw no native <like FSUTIL> way to enumerate hardlinks? Don't even get me started on ADS!)


NTFSLinksView does not see hardlinks. (I put in a request to Nir to add that support.)
Nor does Sysinternals Junction. (You would expect that they would have a utility for this purpose.)
Junction Link Magic also will not cut it. (Looked at this one, some time ago, at which time I decided LSE was the better utility.)


And the command-line based version, ln - command line hardlinks:

[hakibam]

Search Everything... from drives searches for "Computer"".

"::{20D04FE0-3AEA-1069-A2D8-08002B30309D}" was shown but nothing can be searched

i had to downgrade back to earlier version [1.1.4.301] so that if i right click on my computer all file will be listed not the registry name. it affects my efficiency of doing any work.

[void]

::{20D04FE0-3AEA-1069-A2D8-08002B30309D} will show all results in the next release of Everything.