Using NTFS MFT instead of FindFirst / Findnext - feasible?

[Lefteous]

2Hacker

How would I go about that?

Try other programs that use FindFirst/FindNext or write a test program.

[Hacker]

Lefteous,
Is reentering the dir not a good test?

Roman

[Lefteous]

2Hacker
Probably yes although it's not a proof. Theoretically it could be another operation that performs faster when executed twice or an omitted operation.

[Balderstrom]

Everything (ESE) is MFT only. Thus anything that sits above that is ignored -- Junctions, Libraries, SymLinks, (not sure about HardLinks).

If you've mounted a drive to a folder: ignored.
Junction to the UNC path of a drive: ignored.

Everything (ESE) and MFT search is useful up to a point, but with no way to integrate upper-level File System mechanics to the base MFT search - it would be inadequate as a way to populate actual folder contents.

[meisl]

Balderstrom makes an important point here.
If one were to add all that stuff on top, as to make it actually usable - one might end up re-implementing the OS functions. There might still be some performance benefit in doing so but it's the ratio of it vs the effort that needs to be justified.

the two Sourceforge projects you linked to would at least give some clue about what Windows is allegedly doing "so awfully wrong"?

Who says that Windows does sth. wrong?

Well, Hacker does, in a way.
I mean it's still a postulate/open question whether parsing the MFT "by hand" is a worthwhile thing to try.
I'm asking if, in your view, they're worth a closer look because you said they don't look mature to you.

[milo1012]

I'm asking if, in your view, they're worth a closer look because you said they don't look mature to you.

By mature I mean that it does what it says, but looking for the pure "age" of the program,
i.e. how long it has been actively developed and tested and how many people are involved. (just one person each it seems).
It just doesn't seem "ready-to-use".

Also by taking a quick look at the source for both projects it shows to be barely documented or explained, not even a decent help-file.
Of course, code is self-explanatory, but for a low-level access things need to be very clear IMO.
I'll probably need at least a week to understand the core of the program just by viewing the source, not to mention an evaluation for possible flaws.

Anyway, I wouldn't want to integrate sth. like this in a commercial program (and TC prefers Delphi), but, like a said, maybe a plugin.
Especially NTFS-Search just seems to be "unfinished" (and wasn't updated in four years).

[meisl]

Thanks milo1012, that answers my question.
I figure they're not well suited for learning about the low-level MFT stuff (at least for me). Not to mention porting and integrating any of the two.

Thanks again and sorry for asking to sloppily. I'll try to be more clear next time.

[meisl]

Just thinking: what about using the Everything service?

[ZoSTeR]

You can control Everthing via Window Messages to "EVERYTHING_TASKBAR_NOTIFICATION".

See the Everthing_IPC.h in the SDK. The other stuff (sample etc.) seems to be a little outdated.

But currently I don't see how to implement it in a really useful way. A Filesystem plugin would still be somewhat cumbersome I guess.

[sheppaul]

everything is so great. I do not know something behind a technical thing but it's really worth taking the feature of searching ntfs volume into consideration.

I have 8 hard disk (4TB*4, 3TB*3, 128ssd) and general search task puts my patience to the test. Everything search is almost instant. TCMD is specifically a windows file manager. I know there are many things should be considered but there is no reason to reject this great method.

Other than searching task, there is one thing I like.

Folder Size could be calculated much more fast. I guess it's because of ntfs handling. Oftenly, I use ctrl+alt+enter.

I didn't know that folder size can be displayed so fastly Before I found hddb and wizTree.

http://hddb.xp-zed.com/index.html
http://goo.gl/b9swt