Hacker News Reader

Comment by nmfisher | Hacker News Reader

It's amusing (and infuriating) that file search - IMO, one of the most important features for a desktop O/S - has been utterly broken in Windows since Vista.

On Windows 10, half the time it just hangs with "Searching files", displaying zero results. The other half, search simply says "Nothing found", even when I know there is a match. I just tested it with %USERPROFILE%/.docker - open up File Explorer and search for ConfigVersion that appears in config.json. Nada.

I have to resort to cygwin/grep any time I want a search that actually works.

I never had this problem pre-Vista. I don't know how they managed to go backwards on such a fundamental feature.

View on HN

Use Everything instead. https://www.voidtools.com/

This tool is wonderful - mindbogglingly fast. I can't believe how long it has been around, without equivalent performance or consistency baked into Windows. I think I first used this before Vista came out - has it really been that long?

Why doesn't Microsoft just hire this guy? Why didn't they hire him 5 years ago? The internal politics around this feature must be utterly insane.

> Use Everything instead. https://www.voidtools.com/

++This. Does the essentials such as real time [NTFS] drive monitoring from journals, small memory footprint, presents an accessible and responsive cancel dialogue when a operation will require lots of STATs (like sort many files by size), and has good boolean operators and semi-smart parsing of search lines and Bingo, ""quotes, optionally includes paths, stores file class (audio, video, doc etc) in short-index.

For full content search with several viewers and "jump to it and see" preview -- but only for selected document folders, I use DocFectcher. Matching files are presented in a windowpane you can further sort by relevance or -Date (my default), name or size. Reindexing is not done in real time when you change or add files but a small process watches indexed folders and just saves flags of what changes so index update can happen quickly when the main program is run.

http://docfetcher.sourceforge.net/en/index.html

I personally never use search tools; at least, not with files I've created myself. IMHO organising correctly your files using aptly named directories and sticking to that is much more effective than dumping stuff around the filesystem and then having to rely on search in order to untangle the mess. That's why I tend to disable desktop icons; in this way I always have to force myself into opening a file manager and actually decide where the files should be put into.

Yea I was thinking about this and I never use OS search either. I suspect the reason it's "broken" is because Microsoft has the data that says most people don't use the feature and therefore it's not worth the improvement cost.

But they've just recently, with 1903, revamped Explorer as well as taskbar search.

In general, I find it very hard to believe this is a people few users rely on. It's the primary way to launch programs for me.

Do you have a neat and organized desktop? Most people just have a mess of shortcuts and that's how they launch programs. But also consider that most people use maybe 2 or 3 apps all the time and rarely explore outside of that.

> IMHO organising correctly your files using aptly named directories

I have a lot of ebooks on my computer (> 10000). One problem with organising books and other PDFs is that sometimes they fall into multiple categories. (Should a new scientific article on lucid dreaming go into 'brain and cognitive science' or 'meditation' or 'hypnosis' or 'sleep' or 'self improvement'?) I could dump each new file into the directory representing the first category that comes to mind and make symbolic links from directories referring to other categories, but in the end the number of categories is practically endless. Search is in practice the only workable solution.

You can add tags to files instead of putting them in folders, I believe

Yes but conceptually it amounts to manual classification into multiple categories, which is just neverending work in my experience.

Manual classification is still useful to classify documents according to labels that are not present as strings in the books' contents though.

Tagging files on Windows is a horrible experience though, sadly.

Might wanna try calibre.

https://calibre-ebook.com/

My Calibre installation has 10,257 books! That's probably less than half of what's scattered on my drives outside Calibre.

Calibre has nice search by 'title:', 'author:', and 'vl:' but eventually it has still the same problem of endless categorisation.

I'm a data hoarder and I organize meticulously, so I get where you're coming from. But I often need to do searches along different dimensions than the "primary keys" I chose for organizing the directory structure. Search is indispensable for this.

As an example, say I have records related to my taxes - a bunch of documents and images - organized into directories by year, and I want to copy all of the images for the last 5 years out into a temporary directory so that I can flip through them easily. I can browse to my taxes directory, do a search for "kind:picture" then sort the results by modified date and drag the relevant items into the destination directory.

For some types of tasks this is so convenient that sometimes when I'm ssh'd into a server on my home network I'll move files into a mounted network share so that I can manipulate them from Windows Explorer. Clicking around a graphical file explorer is just way less cognitive overhead than stringing together a big command on the command line. Windows Explorer in the Windows 10 era isn't great, but it's much better than e.g. Finder or Thunar, which are my other options on my home computers.

Unfortunately, even that is particularly impractical on windows. I'm not sure exactly who thought up the disastrous library feature, but the net effect is that it makes it really, really hard to organize stuff into folders. The arbitrary top-level boxes MS thought of are always in the way; and they're sometimes an alias for a folder, but in other ways quite different. If truly everthing were easily mountable inside a library, then maybe it would work... but the reality is that people (shockingly) have multiple storage devices, and libraries work terribly with that. But I think worst is just the generally inconsistency; everything is "special" and nothing works quite like anything else. Add to that the fact that all kinds of programs store their "user" data in your documents, using poorly-names hardcoded folder names (including lots of microsoft apps), and pretty quickly everything just turns really messy. I don't think I know anybody - technically inclined or no - that seems to be using the library feature as it was intended; most people either just accept utter chaos, and treat the PC largely as throwaway or hope they can find something using search (oh boy); or they use a parallel structure entirely divorces from the libraries, and live with the fact that lots of the OS apps and views will then make you jump through hoops to access stuff where you actually store it, because the OS always offers stuff like libraries first.

Folders work. Tags can work. Search can work. The frankenstein folder-search monster that is windows 10 used as designed - that simply doesn't work for anybody.

File search seems to have steadily declined with each version at least since XP. The underlying pattern seems to be the combination of more features with a simpler interface. The inevitable result is less transparency for the user. Microsoft's search features have demonstrated repeatedly that this is a bad idea, and what's most puzzling is why they keep doing it.

Google maps is another product where useful features are regularly broken by 'improvements'.

Here's a short search thread with the original 2010 post about W7 followed by a 2011 response and 2014 final experience:

https://windowsforum.com/threads/windows-7-file-search-index...

Some of my scientific instruments are decades old and I like to be able to search back quite a number of years compared to most offices.

It's worth the effort to be the most reliable and repeatable you can get.

I don't like search to be slow or questionable, and of course it needs to return the same results from the same archive every time.

And indexing is not helpful, I usually want to search within every file.

Using a 2GHz processor with adequate memory and identical HDD, with no indexing and background services minimized, Best performance was found with W95, then W98, then Wxp, all on FAT32 volumes.

Wxp on NTFS, not so good.

NT6.x not acceptable.

On a modern 2GHz multicore processor and adequate memory and identical HDD (but different than above), with no indexing and background services minimized, Best performance is found with Wxp on FAT32 volumes. _its nice to know W9x would help out in this situation if really needed

Wxp on NTFS, not so good.

NT6.x less acceptable than ever.

The good thing about Google search was when it would return the same first-page results for anyone anywhere until something different had newly gained higher ranking among everyone altogether.

Going back a lot further, the promise of TV without commercial interruption was so long overdue it was wonderfully realized decades earlier in the 1970's by your friendly neighborhood cable TV company. That's why a private content-providing network was installed to premises to begin with, having better bandwidth than the original communication lines from the phone company monopoly.

Maybe they are all just trying to improve shareholder results through time at the expense of customer results, the old-fashioned way.

It’s relatively easy to implement search - you need only minimize the Levenshtein distance between the search string and the file name string. The difficult part is actually indexing all file names and their string contents on the system. Grep is a different tool, mainly using regular expressions to match strings within files and I don’t think it is feasible to be continually loading the contents of all strings contained in all files into memory to perform fuzzy string matching.

I was always very skeptical about the need for search indexing for local files - how often do you search for stuff to need indexing in the first place? I have a ton of files, certainly more than the average Windows user and i do search for things often enough (at least once a day). To search i use Total Commander (allows for both wildcard/regex searches, archive searches, content search with a bunch of options) which doesn't use indexing at all and search speed was never something i had as a problem (and in general i hate waiting for the computer to do stuff).

In what workflows is search needed so often and for so many files that it necessitates indexing? Even back when i first encountered it (in Vista - AFAIK it existed in XP and before but it wasn't enabled by default) i thought it was a waste of resources and unnecessary complexity.

Totally agree. Back then in XP I'd always disable search indexing, prefetch and superfetch in order to reduce that constant disk activity.

Agreed. updatedb from the locate package is typically the first thing that I uninstall on a new Linux installation. The nightly cronjob definitely consumes a lot more resources over time then it will ever save me waiting time.

Every time?

Searching everything takes lots of time, searching through an indexed database takes less than a second. When in windows I use a locate-port[1] that I use to index any local disks as well as remote network shares of interest. It would take about an hour to search everything.

But an hour wouldn't be that bad, the problem arises when you are not quite sure what you are looking for. Getting the response back instantaneous is invaluable because you can refine your search in seconds.

[1] https://locate32.cogit.net/

And your use case makes sense; but your use case is not typical for 99% of desktop OS users.

And instantaneous results mean nothing if they're worthless. I'd rather let you turn on indexing because you need it and it matches your use case. Leave the other 99% alone.

Indexing benefits the other 99% as well.

Windows default was ok but slow in XP and absolutely unusable since. Any benefit to search would be a massive benefit to millions of people.

Doesn't have to be indexed but would certainly help. I guess SSDs are quick enough many times but it is absolutely essential if a regular hard drive is in the picture.

I use Everything [0], a similar program which is designed to stay resident and essentially become part of your keyboard muscle memory. I have a couple custom shortcuts configured so I can easily open the result, open the result and hide the Everything dialog, or open the folder containing the result.

[0] https://www.voidtools.com/support/everything/

> The difficult part is actually indexing all file names

okay, ...

> and their string contents on the system

... why would you even do that? ls-lR.gz works. And that’s exactly what people wants 80% of time.

the .docker problem is because (IIRC) by default the indexing service is set to ignore a bunch of folders. I think Program Files is also excluded by default, which is fun if you want to run an .exe file.

Reply on news.ycombinator.com