Your experiences with disc catalogers and most wanted/used features

[manimatters]

Lazycat can perfectly do what you want. It´s one of the best of my disc-cataloger tests. Try to get V1.2beta. It´s shareware but has no limit. The development has been stopped 8 years ago 

-Crush (April 06, 2008, 09:03 AM)

Thanks, i've downloadede Lazycat, its perfect for me. Ive got V1.1beta, its shareware, but i dont know if it has a limit or not.

[Crush]

I´ve read somewhere that there shouldn´t be any limitations, but if you find some, please inform me!

[rjbull]

Lazycat [...] Try to get V1.2beta.

-Crush (April 06, 2008, 09:03 AM)

Do you have a link for that, please?  I only seemed to find 1.1a.

[manimatters]

Yeah, even I could only find v1.1a beta.

[Crush]

As I told it´s not available any more and the site is down since 2003. I had a link in the giant list of disc-catalogers->https://www.donation...dex.php?topic=7764.0, but it also seems to be dead now. Lazycat is a very very rare, unknown but excellent cataloger and one of my personal favourites because of some nowhere found special-features. I´d say I´m now the only man on earth possessing the version 1.2beta 

This version removed some errors from V1.1a

If you want it, give me your E-Mail by PM or try to meet me at ICQ and I´ll post it to you!

[Crush]

Only to show I´m still working sometimes on my Disc-Cataloger (it´s not dead!) I decided to prove its incredible speed (I used it as base calculation in former benchmarks at the beginning of this thread) with an old tester. This should be a little bit faster than the version I used for the posted benches, but my newest routine is even faster.
There are some important things to do:

1.) Create c:\tmp
2.) Read some drives with "Read" - if the screen seems to freeze you only have to wait a while. This isn´t important for testing. Rereading of same drives is not possible after searches in this version.
3.) After reading some drives/volumes/CDs/DVDs/Networks you can search for a name. Included is only a case insensitive substring-search. Type in something in the File field for filenames and/or the directory field for directory filtering (you can also type several dirs like "\test\emulation" and click search.
4.) The first search reads all datas from the tmp-folder and in parallel caches the files to memory (you´ll be able to decide how to handle caching in the real release). Next searches will be done much faster.
5.) The strings per second says it all. Each string is a file-entry.
6.) "... seconds searchtime" is the time for the search itself - not taking care of file-activities. Only the first 10.000 lines are shown (release will shows all). This will be faster at the first release version and you´ll see the first results immediately on the screen. A live-search while typing is planed.
7.) Volumes and other infos are not shown in the results. The lines are counted as results - not the real amount of suiting entries! Hey, this is only a version I use for benchmarks and tests for several routines!
If you want to see how fast it would work a.e. with 1000 times your full HD-Drives, you can easily fake this with cloning the lines in the file Volume.vols as often as you like. The amount of searched entries (files, dirs and volumes) are shown at the top. Take care not to insert so many volumes that your memory starts swapping to harddisc!

My goal is something in the style of Lazycat, Locate32 or Everywhere but with different new features and an unbeatable search speed.

[Crush]

Here is a version with a little optimized search-routine using the program path for all datas. It´s best to copy it to an own directory.
Please check the differences: The longer your search term is, the more speed you´ll get.

[Crush]

Question: Has anyone tried it and can post some speeds for different searches? Could someone report test-results, please?

Only use the version attached at the post before and no others. Please start a single search at first to cache the datas and then do the following three searches:
(1)no filename .2)exe 3)a single existing filename in the filesystem)
and post it with the amount of files, directories and partitions/volumes so that I can see how it performs on other systems (also tell me what CPU is running and is it a laptop/desktop running on WinXP/Vista or others).
It would also be great to know the cpu-usage during scanning and search. The most time during filescanning I can see against 4-10% cpu-usage - only the saving of the database at the end of the process takes more time.

I know the development is very slow because of my startup, but I´m still experimenting with new technical features and this week I had a great idea for an incredible big breakthrough and found a new way to check for file/structure changes since the last full update without running a scanner process in the background or using the USN change journal as everything does in only a few seconds. This means this new technique could also be a big speedup in local database-updates working perhaps with other filesystems than NTFS, Network-drives and FTP (I still have to do some further tests but atm it looks very promising).
Example on my Laptop with 2.4 Ghz Intel Core 2: Updating 509654 file entries in 113258 directories on 11 NTFS partitions on a 250 GB HD with windows Vista takes only about 6-7 seconds! Of course a combination with the other methods is still useful. Searching through these big bunch of files takes 0.011 (narrow searches) to 0.04 (all files) seconds.