Rating and tagging system - a few general things and questions

Help & Support
1

Good morning guys! o)

I've been playing with the rating and tagging system and came across some question marks:

  1. It seems there's no way to update ADS rating and tags in an existing set of files without copying all the files again. I use Robocopy.exe for mirroring/backing up, and it does copy ADS data, but it does not update them, once the ADS already exists in the target files. Something I discovered this weekend - to my very surprise.

  2. We could get around point 1) by simply using a special tool, which could copy the ADS data only, but what if you like to sync ratings and tags between two sets of files. You don't know what rating and set of tags was applied more recently, so it seems some kind of datecreated, datemodified for the ADS data is missing to keep it tidy.

  3. The rating system uses a non-linear scale. A value of 1 represents 1 star, whereas a value of 25 means 2 stars, then it's 50, 75 for 3 and 4 stars and 99 for 5 stars. Wouldn't it make more sense to use 20, 40, 60, 80 and 100 for the ratings? So they use a linear scale? Is that something which was adopted from other rating scales maybe - EXIF/Photoshop or something? Sure, this is a first world problem, but it makes it hard to switch to using 10 stars or to some kind of percentage-like rating (unless you reinvent the wheel, being no more compatible with DOs native ratings).

  4. Setting meta information in specific files or retrieving those for showing them in a column, can take a loooong time, since some files will be read and rewritten completely just to update a few bits. For files stored on the network this is even worse. I would still like to see an option to force DO to use ADS meta storage for specific file types. So setting and getting the required information can be done very quickly.

  5. The current way the meta information is stored in ADS, it surely makes sense from a programmers perspective, saving bits and bytes where possible, but since this is data which should be easily read and written by other people and programs, maybe it makes more sense to use something more common these days? I'm speaking of JSON or simple CSV format to store [rating],[created],[modified] for example. So the average coder does not need to handle blobs and byte offsets.

My current thinking is, it's time for a DO meta information handling v2! o)

What do you think?
cya, tb..

2

That comes from Microsoft, more details here.

3

1, 2, 3 and 5 are all things we inherit from Windows.

We have no control over what RoboCopy does or doesn't do.

ADS doesn't have timestamps as far as I know (except on the file itself). Adding timestamps into new ADS fields would not help as reading and comparing them would be no different to reading and comparing the actual metadata.

The format for rating data and ADS comments is defined by the shell and we aim to stay consistent/compatible where possible. We have some of our own formats as well but I don't think it makes sense to change those and break compatibility with old versions. If needed we can provide code or functions for editing things if it isn't possible already.

Re point 4, given all the problems with ADS you just described, you'd really want to use it in cases where it wasn't needed? And have metadata stored in ways only Opus could understand, with the normal tags for a file format potentially diverging from the tags in ADS when different programs read and update the tags? It is a pain when a metadata change has to re-write the whole file (which isn't always the case) but I think it's better to use the file format's tags where possible.