For a while now, I have been using ntfs-ads as a solution for my own custom properties/columns, for both Opus and Everything. but its been a never ending headache, due to their fragility with cloud,non-NTFS volumes and other cross tool inconsistencies.
Everything recently came out with its .metadata.efu Specification, Everything's indexed nature, means lookup is free.
I have new solution in mind, something very simple and less headache prone, use .metadata.efu as a single source of truth. Its already implemented in Everything, so that's half of the work done for me, I just need it in Opus.
Two questions
Is this actually doable with current Opus scripting (JScript columns, evaluator, etc.)?
If so, what's the best way to bridge Opus and Everything SDK3? I can think of a few routes:
Read the .metadata.efu CSV directly from the script (simple, but loses Everything's indexed properties and I'd have to reimplement the directory hierarchy lookup)
Query Everything's HTTP server via XMLHttpRequest (no helper process, but not sure the full property set is exposed)
A persistent background exe that holds the SDK3 connection and answers queries from Opus via stdin/stdout
Spawn a helper exe per file (probably too slow)
A native Opus C++ column plugin DLL linking SDK3 directly (fastest but most complex)
Happy to hear from anyone who's done something similar. @errante, curious what your take is given your experience with both tools, and interests in sdk3 for Opus.
Am running Opus 13.20 and Everything 1.5.0.1404a on Windows 11.
Yes, in fact a tool like that already exists published on this forum. Assuming you created the custom column following Everything’s official procedure, you should be able to access that data through it.
FYI, I haven’t tested EFU with custom properties, so I don’t know if they work.
You should test it first only in Everything/es.exe. I haven’t tried it myself because IMO they’re not a better option than storing the data in ADS (in fact, if you read your own link you’ll discover their limitations).
Note that EvColumnizer isn’t intended to be used in searches (I’ve also discussed this on the forum), but since you can call Everything directly from Opus for that, it shouldn’t be a problem.
I think it is, am really frustrated with ADS, with having discovered yesterday the final strat, that is syncThing strips ads-stream even when syncing from windows to windows systems.
Voids system is elegant, one metadata.efu per directory, no paths just filenames, meaning it will work everywhere, on home system, on portable system, since it does not use absolute paths. the data would be usefull even on non windows systems like android, and of course the "open standards" its using doesnt hurt, long term anyways, as opposed to the closed ads-stream.
The only issuge I can see is the orphan issue, which can be solved a number of ways. SDK3 being the obvious one, also everything journaling system, as well, which can log every move,copy, rename, etc to a text file system wide. And of course Void himself, if he decided to go ahead and make it part of Everything.
Anyways thank you for your answer and also for your script, which I overlooked, I will be using it for this need. Will report in its thread if the metadata.efu works with it.
According to the manual, data in .efu files is cached, so if you modify the file, the changes aren't automatically reflected. You need a manual refresh. And AFAIK, there is no programmatic way to tell Everything something like "refresh the data but for only these specific files". Depending on the context, this could be a problem if your database is somewhat bigger.
Sure. Now that I think about it, the way you access these custom columns via es.exe is probably not the same as how you access them when mapping ADS values as custom columns. Besides defining the name in the .efu file, do you need to register that name somewhere in the Everything configuration?
Probably EvColumnizer would need to be updated to allow the user to enter the names of those columns.