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.
> 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.
I think most people would expect
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)
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:
could also be written as:
(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
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  ... much faster than WinDirStat, which I see recommended way too often.
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  to keep up to date? It's mentioned in the settings
And yes I do believe it uses the USN Journal to stay up to date.
NTFS stores the name in the MFT instead, which makes hard links a bit weirder.
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?
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.
Also MS already index file contents by default, it just sucks at it. There have been several occasions where I use the find file by name syntax and Windows can't even find the file in the current folder.
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.
 - https://github.com/facebook/osquery
1) How/where are you storing the index
2) Have you tried this on large (30+ TB filesystems)?
It would be nice to omit the select and the quoting; my suggestion would be that
fsql "select * from ..."
select all 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.
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.
Not what I suggested; yes they are shorter but that's not the point. Can you find a longer name than for `select` that is more appropriate?
I sympathise but for interactive shells the ergonomics are different than for most languages.
Even then I don't mind long names but I do mind hitting the shift key. Which means avoiding most punctuation.
as a fp geek
In zsh you could also "alias select=noglob command select" and it wouldn't do wildcard matching. Then you could use
select * from ...
https://systemswe.love/archive/minneapolis-2017/ivan-richwal... - "Metadata Indexes & Queries in the BeOS Filesystem"
If you are splitting strings (from output of `ls -l` presumably) for such tasks, then definitely take a look at find.
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.
sort file1 file2 file2 | uniq -u
comm -23 <(sort file1) <(sort file2)
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
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
I'm specifically writing it to find any log file that isn't being pushed into our third party logging service. It's a surprisingly difficult problem, especially considering the amount of tech sprawl that's accumulated. Since it's also a relatively low latency environment, it has to be written in a way that doesn't add too much load (without core isolation..).
Also, thanks for the article! Super interesting. Think that'd be better than implementing something on top of sysdig?
I wasn't aware of the polling limitations of sysdig, but it definitely explains some things I've seen in the past. This is definitely going in my toolkit. Cheers!
Edit: dammit, spelled his name wrong.
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.
Good point though, I'll make a note of that in the README.
Thinking about a use case is quite hard. Anyone?