Forum Posts Feed
file searcher with user-defined metadata columns (Windows)
< Next Topic | Back to topic list | Previous Topic >
Posted by jimspoon
Feb 25, 2021 at 10:50 PM
UPDATE: from author of Voidtools Everything:
Display, searching, sorting by and indexing tags is mostly complete.
There’s still a little more to do before an alpha release.
I still need to add support for editing tags within Everything which should happen during alpha/beta.
https://www.voidtools.com/forum/viewtopic.php?f=2&t=9689
Posted by WSP
Feb 26, 2021 at 01:12 PM
It’s very easy to do this sort of thing in MyInfo. You simply create a new attribute, which then appears (if you wish) as a separate column in the notes list panel. You can then type “done” or “yes” or (in my case) “y” in that column when you complete it.
I use this procedure daily. If I am compiling information for a blog, for example, I set “Blog” as a column so that I can readily spot if an entry has been posted yet. I can of course do the same thing with a tag in MyInfo, but a column in the notes list is better visually.
The “Blog” column, incidentally, can be sorted if I wish. That instantly arranges all my unfinished items together in the list.
Posted by 22111
Feb 27, 2021 at 10:58 PM
Hi jimspoon,
you say, “an ADS is no different from the unnamed $DATA stream when it comes to where it is stored - depending on length it might be resident in the MFT or non-resident. If non-resident a search program would have to follow pointers to clusters and index the data found there.”
As for the former, I don’t know, I have never heard of ANY ADS stored in the MFT, and then it would probably not being named as such?
I suppose though - I might be wrong here - that the NTFS “file attributes” are stored within the MFT; unfortunately, their list is finite, i.e. neither the developer nor the user can create any other.
For “attributes” within the files, you say it’s up to the developer, which is true, but most file formats are standard formats, e.g. for pics, audio…, and I think they have a FIXED set of possible (internal) “attributes” which the developer then can “use” (i.e. make available to the user) or not, but the developer cannot (I might again be mistaken here) create further, specific (internal) “attributes”; this doesn’t apply of course to new, proprietary file formats but users nowadays tend to avoid those and will certainly not accept them in the pic-vid-audio field.
EV has a (default = “on”) setting for EV also indexing those NTFS file attributes; except for your “C:\” system drive which you should leave alone of course, you could use “hidden” and “system”, and their combination, as 3 different “ToDo” indicators, which, thanks to EV, could bring IMMEDIATE, sorted “ToDo”, “Project” lists, etc. onto the screen, even spanning elements from your whole system - the interest here is that you don’t have to fiddle with the file names, and “ToDo” indicators and such should indeed leave the file names alone, tagging within the file names just should be made for non-ephemeral indications / referrals (to avoid link-breaking, among other things); those lists are also exportable, etc. (It’s even possible to do it by command-line, i.e. to trigger STORED “filtered and ordered searches”...
As for numbers in file names, in many cases and for private use cases, these will be years, i.e. 19xx to 20xx for movies, CDs, etc., or even years-and-months for pics (e.g. 2004-11); the necessary regexes will be utterly simple.
wsp, I had tried the MI fields in version 5 for “real use”, and MI crashed. Then, in MI mid-v6 (i.e. not early 6, not the latest version either), I just “wanted to know”, and on a modern PC (where everything else works just fine), I just created some 10, 15 (certainly not 20 or more) items, and with some 5 or 6 fields, with very simple data, numbers without decimals, short strings, simple (not even combined, and I don’t remember if that would have been possible) filtering then IMMEDIATELY CRASHED that very tiny, very simple MI file, and I never spent another minute with that.
(I had a full version of v6 and had intended to apply it to a real whilst limited use case, so I was interested in it functioning well, not in confirming some bad prejudice (“it’ll crash again”: no, that was some 8 years and many minor versions later), but I don’t have any use case for a program which crashes less than 5 minutes into its first use with minimal data.)
Now, I’ll wait some other months, will then try again with a very simple, tiny trial set-up. Considering that v7 is said to have changed the underlying DB (SQLite now, like UR and RN?), those problems may have been resolved indeed, but prospects allured by those fields should be aware of possible problems before buying hastily though, all the more so since the (possible) use of SQLite is not, per se, a guarantee that all will be okay: It was you who told us here that once you brought the (also SQLite-driven) CintaNotes to its limits, things didn’t go so well anymore…
And in v5/6, users complained about the lack of different sets of fields in different sub-folders within MI: Whenever they wanted to use a certain set of fields for a certain set of items, and another set of fields for another set of items, they thus were forced to create multiple DBs. (And no, that’s not a limitation inherent to the use of a relational DB in general or of SQLite in particular, it’s just lazy programming; I know how it’s be done, within a SIMPLE DB setup, NOT by multiplying DB tables or such, which would be as totally unnecessary as it would be totally ugly indeed.)
MadAboutDana (another current thread): Trying just another app? Hoho! There are spouses who’ve got 300 pairs of shoes within their walk-in wardrobe, but you don’t call them “collectors”, they swear they needed them, and they will certainly be useful again (both, spouse+shoes). That’s an expensive hobby if those shoes are “Prada” and the like - men, on the other hand, would be ashamed to pretend that multiple items of (for the most of them, perfectly) IDENTICAL use would be needed in droves, so they do it all the like, but with pretended DIFFERING use - technical stuff, books, and apps vs applications even are quite cheap, by comparison - let alone the Pradas -, at least before you go into the subscription trap…
It’s exactly the same phenomenon though, just in its more manly, less pretty shaping, since we all know that with app x, y and z (and then, it all will begin again with abc, over and over), there will be NO thinking enhancement either…
Newbie alone, in yet another current thread, being excused for earnestly hoping for that. And, to answer the question in which category to file TheBrain, in again another thread: Into the Scambox, naturally! And yes, if it really helped, instead of just pretending while in fact slugging your thinking, it’d be worth it’s annual subscription, per month… (But they know that, too, and wouldn’t hesitate a sec to charge you accordingly if it worked.)
Posted by 22111
Feb 28, 2021 at 10:46 AM
I forgot, in my post immediately above this one, and especially since you mentioned the path length problem: There is no dichotomy “ordering vs. searching”, both should go hand in hand, ordering should FACILITATE searching, and then, searches are so much more simple and precise.
“Everything” differentiates between “in path” and “in filename” and “suffix”: too complicated for me, I search mp4 by .mp4, wav by .wav, and so on. Music is m: and Jazz is m: \j\ and “sax or piano” (just an example) is m: \j\ \s\|\p\ (my EV preference is (default) OR over AND; you can switch that).
For guitar, I could also write, m:\j\g\ but to do the “tagging” by sub-paths allows for searching for these tags even when they do NOT follow precise other path sub-strings, e.g. k: is comedies, \c\ on drive k: is “other comedies”, whilst \cc\ is criminal comedies, \cr\ is romcoms, etc., \a\ is anglo, \f\ is France, \i\ is Italy, and so on, then k: \i\ is ALL Italian comedies, whatever their subgenre - note that the real path could be k:\i\cr\... OR k:\cr\i\... or could contain even other sub-tagging, so “tagging by discrete subpaths” is much more powerful than just “search for path substrings” where “wrong order” would then make impossible the retrieval.
“Discrete” being the key-word here, but then, in totally different contexts (films vs. music here, on different drives anyway, i.e. k: or t: (thrillers) vs. m: (or o: for opera and j: for jazz, etc. in your possible, theoretical case), “identical” further sub-tags could be of very different meaning. To bring a real-life example, “\j\” in film is “Japan”, whilst Japan in music, for me, is “\jap\”, since, for me again, Japan in music is “exotic” whilst in film, it’s an important “sub-category” - if I had enough jazz music to fill, say, 4 TB, i.a. a drive on its own, the “j” would be in j: anyway, and I could and would rename the \jap\ to \j\ - “simplify your life” > “simplify your retrieval, by smart tagging”.
In jazz again - I bring all those examples for hinting at the general basics which also apply to work environments -, \s\ and \p\ and \t\ (for trumpet there) are the CD’s main classifications, and if some ripped \p\ CD (track) is also important for \s\ for example, I put a space£s into the album or file name, more precise searches would then be m: \j\ \s\ | £s i.e. m: \j\ (\s\ | £s).
Ditto for films, think of “black comedies” (if you don’t want to create their own sub-genre), or of brilliant screenplays (space£sFamilyname), of outstanding photography (space£pFamilyname), or just of the most beautiful endings, so in “La dolce vita”, there is a space£e) - the trick being, once you use such “codes” on a regular basis, you will not have to look them up anymore.
EV also lists any “finds” on currently non-connected drives, which is extremely helpful, but which is a problem for backups whenever you don’t search for a tag (and where you would also put in the drive (k: or whatever), but for some “real text string” - name, whatever - e.g. in the fullpaths / file names, since most of the time, you would not want to have “de-doubled” all entries, e.g. the very last part of your path would be the artist name in the form (e.g.) \Nyro, Laura\ (the “\\” obviously not being necessary for retrieval here), and then, EV would list all her tracks on m: AND on the n: backup if you don’t also enter the “m:” every and every time…
Similar for all those “\\” WHERE they are necessary for discrete searching, and then, entering those multiple “\\” in “\1-or-2-chars\” again and again is no fun either, and thus, you need just a little macro, with an inputbox to enter some “simplified string”, and after pressing return, it would work on your string and amend it in the way that then EV does the “correct” search:
If you enter k: it would automatically add !l: (your backup drive for k:, ditto for t: and !u:, for m: and !n:, etc.: for “k:” in the string, add ” !l:” to the string, etc), and for every 1- or 2-char string, it would put the necessary “\” before and after (replace every “[a-zA-Z]{1,2}” by “\$\”) - note the regex is in the macro, not in the EV search-string, but you can also, for other use cases, combine regular and regex search within the latter.
And then, any info already comprised, in whatever form, even by just a discrete \1-char\, within the path, will not need to be repeated within further-down folder, or then the file names, even though, in the above music examples (i.e. album names), it sometimes will (“An Evening with ...” or “Rachelle Ferrell Live in Montreux”), even when the sub-folder higher-up (i.e. on the “artist” level) already says “Ferrell, Rachelle”, on the other hand, with the encore-higher-up folder naming “\j\v\w\b” instead of of “\Jazz\Voice\Women\Black\”, it’s again 15 chars less than “written out”, and that also and foremost applies to retrieval…
(And yes, that album is a very special one… and no, the “Black” is for the very different vocal character - it’s almost “another instrument” in most cases -, and not for (easily alleged here) “racial” reasons, and then, in jazz and other (non-classical) music, around 3/4 quarters of my (now, ripped) CDs, voice and other instruments combined, are “black”, so…)
Posted by 22111
Feb 28, 2021 at 10:49 AM
Sorry, that would have been \$, not $.