This is a quote from an older post by @Leo in 2022:
I disagree with this perspective for the following reasons:
Descript.ion is not just a mechanism that works, but it allows for much faster finding of important content notes even without indexing; also useful to add tags (which is more elegant via descript.ion than adding these to the filename, as some do). So that's the "fast" argument. And ease of indexing is also part of this point.
Descript.ion also allows for storing data that is only accessible via some runner, so it can be accessed faster (and independent of the runner) later on. E.g. I do often store video chapters (a.k.a. menu) data in descript.ion, for lookup reasons (can also be indexed).
Descript.ion also serves to overcome limits in the number of characters one can put in some other fields defined by certain format-dependant standards (e.g. no limit to 255 chars. or even less).
For those reasons, I have a change request
EDIT: some clarifications added below, because my explanation was not understood the way I intended.
The functionality that Opus offers for dealing with descript.ion files is great because it maintains the link with its descript.ion data in case you ad hoc rename the original file, and it will even copy the descript.ion line of a particular file from one descript.ion file to another when you copy/ backup or move/ archive a file. This is very powerful and we do not need to program anything to make this work.
Still, I stopped using it, for one single reason: I wanted access to NTFS a.k.a. ADS (Alternative Data Stream) comments through Opus too, and unfortunately in Opus it is one way or another: both use metadata.other.description (or the slighly different metadata.other.userdesc) object (or handler) to redirect a comment either to ADS or to descript.ion. The Opus guys decided to put a switch between these two: you have to choose one of these.
I would propose that Opus gives us an alternative handler to write to descript.ion - for instance something like metadata.other.descript_ion or metadata.semaphorefile.descript_ion. In the options, this would require to set description to write to descript.ion (as it is today), but an additional option would still make the description and userdesc fields still being written to ADS, while the alternative handler (e.g. metadata.other.userdesc) would write to descript.ion.
It seems to me that this would not require significant re-coding. This setting should, of course, for historical reasons, be inactive by default.
I'm not sure I fully get what you're asking.
Do you want Opus to save the description in the NTFS ADS and only keep the link with its descript.ion file? Meaning they wouldn't stay synced with each other (not automatically in any case).
Or are you asking that, for example, if I manually edit the descript.ion file, that change would "automagically" also show up in the ADS?
Because if it's the second one, I don't think it's just a matter of simple re-coding. That would mean Opus has to constantly monitor every descript.ion file to keep it in sync with its ADS counterpart whenever a change is detected.
And if it's the first one, then why would you even want the link to the descript.ion file? Opus would only show one description column anyway (the one from the ADS). Also, the ion file wouldn't show the latest value.
Do you have a real use case example that shows the usefulness of what you're suggesting?
I'm asking because in your particular case there might be a workaround (which, if you know me, obviously means some scripting ), depending on what exactly you mean.
It seemed pretty obvious to me that the solution I propose would require that, for instance, metadata.other.usercomment redirects to the ADS field, while something else would be needed for descript.ion - for instance metadata.other.descript_ion ... But reading your reaction, it occurs to me that my request might have been less than optimally formulated by leaving out the suggestion about another kind of object (or 'handler' as we might call it).
Your suggestion that descript.ion "wouldn't stay synced" with the file is probably caused by my incomplete formulation - as is your suggestion that I want descript.ion comments be an exact copy of the ADS comment (no I don't). Of course the file should stay in sync with descript.ion - that's the whole point of it. But using metadata.other.usercomment should not block access to the ADS description. So indeed it requires two different handlers if you ask me.
Now if you have a workaround for that, I can imagine two way: (1) one could be that I could configure Opus again to keep descript.ion in sync, and you know another scripted way to get and set ADS description. However, if it would require me to migrate ADS description data for thousands of files to a different metadata field in ADS, I would say thanks but no. (2) The other way around would be to manage descript.ion through scripts (which I already do!) - but then I cannot use the powerful Opus-solution to keep descript.ion in sync, and I need to use an even more complex scripted solution to "mimick" something Opus is perfectly capable to manage by simply activating a checkbox. (Not using what's already there seems pretty ridiculous to me).
I just need a different way to access descript.ion data (plus re-activating the Directory Opus syncing mechanism) while at the same time keeping metadata.other.usercomment for ADS.
You asked for a real-life example. I currently use ADS description to store very basic, but core information (e.g. for video's: its original url and identifier; for e-books: author, publisher, isbn). In descript.ion however, I store things that I want indexed for search: keywords, notes. I also use 'identifiers' in descript.ion data lines: they identify different kinds of data (e.g. a "VideoChapters" ID identifies a list of video chapters (a.k.a. "menu"), which I've fetched from the file and stored in flat format in the file's descript.ion line. I can request chunks of a descript.ion line based on this "data identifier" and search through them - which fastens search greatly. You could say that I use descript.ion mostly as a flexible index. I certainly use it also to store more data than usually fits in official, format-specific fields.
To be honest, I don't think I've ever used a descript.ion file in Opus. A bit off-topic, but what happens if you toggle the corresponding options between using the .ion file and the ADS? Does it trigger some kind of sync between them?
From your use case, I'm not sure it my experience would help much here, but I had a similar need to add some custom fields to certain files. Mostly work stuff, like an ID, release date, things like that. And instead of trying to abuse the description field (which IMO really isn't convenient, since all the fields get "lumped" together and then you have to come up with some way to parse them, plus searching becomes messy if you want to treat the data as more than plain text), I went with the Opus scripting route to add/edit/manage custom fields (stored either in an ADS or in an external file). Think of this solution as regular script/evaluator columns, with the special perk that you can set values on them. Sure, it's a bit more work, but in my case it was definitely worth it. And you can also use Everything for indexing those values too, so for me is a win-win scenario.
But you use external files too. And I suppose you have a certain structure in those files (which I would find interesting to know, certainly if they represent something like a formal standard). You certainly did some hard work to develop it. It's the same situation for me: I use descript.ion lines that in fact contain what you may have preferred to store in separate files - but I use the standard formatting rules of descript.ion. I developed a system to get from those lines different sorts of data based on keywords (formatted in a certain way). Once programmed, and it works, there's no reason why I would abandon it for another system.
Anyway, I'll have to think further about your suggestions. But the mechanism offerend by Opus (to sync descript.ion content with filenames) remains definitely my main argument why I would like to use it. It's all already available. I only disabled it because it blocked access to NTFS comments.
Of course. If it works for you, that's all that really matters.
My comment was more about how, as a workaround, you could keep in Opus the compatibility with descript.ion files enabled while also creating and maintaining your own ADS. That would let you have both options, which, as I understand it, is what you were asking for originally.
This approach would also let you have not just two spaces for descriptions (one in the descript.ion file and another in ADS), but as many as you need, since once it's set up, scaling it doesn't take much extra work.
And moving the content of your description that's currently stored in Opus's built-in ADS should also be relatively simple, since it could be done programmatically without too much interaction from your part.
At first, I had a single file containing all the custom fields and other data in JSON format (both for the ADS and the external file versions). But when I wanted to make it compatible with Everything, I realized there was no way to make that format work, so I'm switching to a new one (two different formats this time, though I haven't decided yet). And that's the nice thing about building your own system, you have the freedom to tweak it however you need.
And how would you do this in Opus if use of descript.ion is activated? Is there a 'secret handler' for this in Opus? Or are you rather suggesting to use some third party tool to do this (using PolarGoose's solution, or the new Run() methodof Opus) ? It would be much nicer and "tighly controlled" if it was integrated in Opus.
PS. Thx for your explanation on your own text format. I agree that your own solution may be more flexible. But I am "oldskool" - I would prefer a standard over my own solutions at any time.
), depending on what exactly you mean.