No need to "index" all the files because it reads directly from the MFT. If you create a new file matching the search pattern it's already sitting in the results window by the time you alt-tab.
Also, the "directory size" equivalent of Everything is WizTree [1] ... much faster than WinDirStat, which I see recommended way too often.
[1] http://antibody-software.com/web/software/software/wiztree-f...
Also when you launch it first, it's going to be empty and says it's scanning your folders and it takes a little bit until you see something.
I think it is still indexing (maybe using the MFT instead of recursively listing files and directories), it's just a lot better than Windows search indexing. And it might use this [1] to keep up to date? It's mentioned in the settings
When I last looked for a Linux replacement for it, none had the real time updates or the instant search ui, and even those that claimed to index the file system for a quick search were very slow. I actually ended up writing my own hacky and rudimentary GUI over locate to achieve something that fits my needs (and of course doesn't support real time updates).
Maybe things changed since then? Any chance that the HN crowd knows of a good Linux replacement for Everything?
https://github.com/junegunn/fzf
It integrates well with UNIX shells, editors (VIM integration is excellent), git log search etc. It's really versatile.
Of course, there is also q:
for something that is more like the software described by OP.
Also integrated with the KRunner framework.
filename dm:>=16/05/2017 size:5mb..9mb parents:>=3
I couldn't find anything on the FAQ and I remember a similar tool posted here on HN and people complained that it called home for some search functionality.
Bill Gates described it as his biggest product regret (2).
I remember I thought it was brilliant. Too bad it was probably a little bit too futuristic for its time, as for a few other things they launched when it just was not the right time... the clunky Tablet PCs (3) were for sure another example.
(1) https://en.m.wikipedia.org/wiki/WinFS
(2) http://www.zdnet.com/article/bill-gates-biggest-microsoft-pr...
> We had a rich database as the client/cloud store that was part of a Windows release that was before its time. This is an idea that will remerge since your cloud store will be rich with schema rather than just a bunch of files and the client will be a partial replica of it with rich schema understanding.
Then he confirms few comment later that he was talking about WinFS.
https://www.reddit.com/r/IAmA/comments/18bhme/im_bill_gates_...
* https://hal2020.com/2013/02/14/winfs-integratedunified-stora...
* https://hal2020.com/2013/02/14/winfs-integratedunified-stora...
* https://hal2020.com/2013/02/25/winfs-integratedunified-stora...
* https://hal2020.com/2013/03/10/winfs-integratedunified-stora...
I think most people would expect
/home/geokon/program1/src/
and
/src/program1/home/geokon
to have pretty much the same content
A tag based file system that makes the two equivalent would eliminate all sorta of annoyances where you can't decide how to structure your file hierarchy (should you have bin/program1 bin/program2 sr/program1 src/program2 or program1/src program1/bin program2/src program2/bin? both layouts have their advantages).
Something like a "path/path/bin/path/path/bin" wouldn't work.. but it's hard to find a case where you really need it. And the vast majority of time the subfolders aren't strict subsets of the parent (like mammals/dogs mammals/cats mammals/whales - where dogs/mammals would be a little weird)
e.g. /home/geokon/program1/src/foo.c
could become: user=geokon/program=program1/category=src/lang=c/name=foo
You could potentially decide that the order of the attributes is not significant, only the set of attribute-value pairs.
Downside: Too much typing. Although, maybe you could allow standard aliases for attribute names, so that:
user=geokon/program=program1/category=src/lang=c/name=foo
could also be written as:
u=geokon/p=program1/c=src/l=c/n=foo
(I think the attributes should be first-class filesystem objects, just like files are, as opposed to just text strings. Some of the values, e.g. an enumerated value like lang=c, should be first-class objects as well.)
I also took some inspiration (in concept not syntax) from https://en.wikipedia.org/wiki/Faceted_classification such as https://en.wikipedia.org/wiki/Colon_classification
Being too different from what everyone else is doing would be the real killer, however.
Also see the Pick operating system.
In some ways, Microsoft is on the way there with the way PowerShell works, and the ability to script things through OS functions that return objects which can be queried. If we ever see a WinFS, it would be very powerful combined with PowerShell
It would be nice to omit the select and the quoting; my suggestion would be that
fsql "select * from ..."
select all from ...
select from
from ...
So maybe select and from could be shortened to sel and frm.
Or just ... Why even bother naming fields. Just make <space> enter return everything from anywhere from all time for all people on all platforms.
How many times are we going to have this ridiculous suggestion that less characters/words is automatically better.
This is 'short/arrow functions' (pick your language) all over again, and invariably ends up with the situation where the new syntax is just fucking impossible to read at first glance, because it has so many variances.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Parens are optional. Unless you have no arguments, then they're required. Curly braces are optional, unless you want more than a simple expression, or no return or to return an object literal, then they're required.
I grow weary enough of this bullshit notion that code must 'look pretty', but when you're using "less characters is always best" as the definition for 'pretty' it just becomes unbearable.
In zsh you could also "alias select=noglob command select" and it wouldn't do wildcard matching. Then you could use
select * from ...
SELECT distinct(l.name)
FROM lsof l, lsofer_runs r
WHERE l.lsofer_id = r.id
AND fd_type = 'REG'
AND l.fd ~ '[0-9][uw]'
AND l.name like '%log'
GROUP BY l.name, r.hostname
ORDER BY name
[0] https://news.ycombinator.com/item?id=8528460 [1] https://news.ycombinator.com/item?id=12600790
Any examples where this would be better than using find (with the occasional filter thrown in) ?
"select name from foo where name not in (select name from ../bar where date < ...)"
I'm usually fine with `find`, but when doing things more interesting than just "find files in this directory that are not in that directory", while uncommon, tend to make me think about my pipeline a bit.
Contrariwise, I rarely see a non-trivial `find` invocation that does not have a few bugs. (including my own!)
>eventually every system that contains information that can be queried will have a sql interface
https://systemswe.love/archive/minneapolis-2017/ivan-richwal... - "Metadata Indexes & Queries in the BeOS Filesystem"
1) How/where are you storing the index 2) Have you tried this on large (30+ TB filesystems)?
If you are splitting strings (from output of `ls -l` presumably) for such tasks, then definitely take a look at find.
Good point though, I'll make a note of that in the README.
[0]: https://developer.apple.com/library/content/documentation/Ca...
[1]: https://developer.apple.com/library/content/documentation/Co...
[0] https://msdn.microsoft.com/en-us/library/windows/desktop/bb2...
Something that has a self-hosted Web Interface, and an engine that I can point at some file servers, and let it index the files to it's hearts content. All I then have to do is search the index 'google style' for my files.
Any suggestions?
--
Thinking about a use case is quite hard. Anyone?
