Total Commander

Lefteous wrote:

system properties are TC content plugin fields too

No - I'm talking about the Windows property system introduced in Vista.

Don't forget that one may use simple WDX plugin that will retrieve Vista's properties. So, theese properties are also TC content plugin fields (potentially).

I don't know if system search indexes more properties of files but perhaps OS will update index automatically on each copy/move/delete operation - within TC we can't catch all file operations so index will lose its actuality.

Simplest search DLL implementation may support only system search and no content fields indexing - for most people it will be nice already (in most of cases we search filenames but not attributes). E.g. I don't need to index content fields so simple DLL that use e.g. Everything to retrieve filenames to filter will be good for me - so I will use such search DLL implementation.

Lefteous:
I suggest that you capitalize "Windows search" in your previous posts.

It was when you told it doesn't work with XP when I realized that you mean the indexed one.

At least I think you mean the indexed one.

2MVV

Don't forget that one may use simple WDX plugin that will retrieve Vista's properties.

ShellDetails offers limited support for the Windows property system but that doesn't help at all. It would have to work the other way round and sounds quite cumbersome.

2m^2

I suggest that you capitalize "Windows search" in your previous posts.

I don't think it's a big deal. Of course I was talking about the Windows Search previously known as Windows Desktop Search.

I have done some research on the NTFS file system, and it's not so easy as I thought to make such a search. Reading just the MFT (master file table) isn't sufficient, it contains just the file names and some attributes, plus a pointer to the data (or the data itself for very small files). The directory information isn't part of the MFT. So my guess is that "Everything" does something like this:
1. Read the MFT
2. Check which of the entries are directories
3. Sort them by location on the harddisk, to make reading them faster
4. Read in all the directories to build the full name index (with directories)
5. Use the Windows notification system for the entire drive to be informed about new and modified files

I think that I could write that too without the need of source code, but it would certainly take a while. Is it really worth the efford? Other possible solutions:
1. Call the "Everything" API (requires installed "Everything" tool)
or
2. Expand WM_COPYDATA handler to accept file details to be displayed in TC file windows (e.g. in form of WIN32_FIND_DATAW records or so).

What do you think?

Christian,
OK, as I understand it, there are three options:

1. Implement the MFT search internally. Slow to code, but it would not depend on 3rd party tools and could be enhanced in the future. Full integration into TC.

2. Use Everything. Dependent on Everything. If the author chooses not to support the next version of Windows or anything the like, we're out of luck and your whole coding for the API is useless. Also, the API could change. And the users would have to have the correct version installed. Etc.

3. Allow external programs to show search results inside TC. This is a very intriguing idea, because it would not be limited by your time and could also add WDX support, indexing support, etc. On the other hand we must consider what we would be able to do with the search results. Could we pack them? Display with custom columns? Multi-sort? Would the ignore list apply? If everything that can be done function-wise internally can also be done externally then I vote for this external option.

Roman

2ghisler(Author)

What do you think?

The best possible search should work out of the box - I don't really care how this is achieved (MFT scan, indexing or whatever). It must work transparently (no new user interface or something like that - though the current could be improved).

Hello
I'm not a good programmer, so I have no good idea to choose one or other solution.
But what I say is : it is a very VERY good news that Speedup File Search will be implemented in TC.
Cheers

Lefteous wrote:2ghisler(Author)

What do you think?

The best possible search should work out of the box - I don't really care how this is achieved (MFT scan, indexing or whatever). It must work transparently (no new user interface or something like that - though the current could be improved).

I also think that it would be far better to use TC interface than any other...but when I'm thinking that this could fix the issue with search being modeless, I think it might be worthwhile.
And I'm definitely sure that the new search should be as powerful as the current one, wdx etc.

I think Everything support would be enough, since Everything is donationware.

ghisler(Author) wrote:1. Call the "Everything" API (requires installed "Everything" tool)

I think this is the simplest way, but this must be done via TC admin tool because accessing Everything requires same access rights as Everything have.
But if speed search code will be placed into external DLL in TC folder, users will have possibility to use any external (or even fully integrated to that DLL) search engine, also this way will allow to have elevated part of plugin always waiting in background instead of starting it time to time.

I would suggest locate32 be supported as well aside from everything. I use locate32 because I can use enhanced searches ( by date, size, etc ) where you cannot do that with everything ( very limited ).

Any search engine may be used if search functions will be placed to external DLL (someone will need just to make such DLL for each search engine).

http://forum.voidtools.com/viewtopic.php?f=9&t=1675

everything is updated.

What is the Everything service?
The Everything service is a Windows service that indexes and monitors NTFS volumes.
This allows the Everything search client to run with a normal user account with-out the need for administrative privileges.

That's great that they have added service/client support so we don't need elevation to use it now.
Thanks.