This project has moved and is read-only. For the latest updates, please go here.

Registering handler globally for all file types?

Apr 28, 2014 at 7:49 PM
I suppose the answer is no, but is there a way to register property handlers globally, and not per file type? Something akin to * or AllFileSystemObjects.
Apr 30, 2014 at 8:17 AM
Hi sxin

You're right, my understanding of the property system is that there is no way to register a property handler for all file types. This makes sense when you consider that Microsoft eventually went with a design that required a property handler to understand the format of the files whose extension, or extensions, it handled.

I will soon be able to offer some help, however. I have been testing a version of the File Association Manager that supports selecting multiple extensions, so that you can add or remove the File Meta property handler to or from many file extensions at once. I plan to release this as part of a new release candidate for File Meta 1.2 within the next few weeks. I will repost on this discussion when I do so, so that you are notified.

Apr 30, 2014 at 2:23 PM
Thanks Dijji.

Microsoft's shortsightedness is unfortunate. Instead of a simple and clean solution, you have to litter the registry, and to keep updating it continuously with new filetypes. At least the idea of concentrating the property handlers config in its own subtree, instead of adding more junk directly to the file classes, was a smart move.

One thing I thought of was that even if there's no Microsoft support for multiple handlers, it should be possible to chain them "manually" by keeping in the registry a list of the old handler(s), then loading them manually and calling the needed interfaces directly.

I still dream of a good full replacement for Windows Explorer that will override it in the shell, but considering I'm yet to even find a satisfactory standalone file manager, chances are currently slim.
May 5, 2014 at 12:20 PM
Hi sxin

Support for selecting multiple extensions has now been released as part of File Meta 1.2, which is available from the Downloads page.

The chaining capability is an interesting idea. Suppose, however, that you chained one of the built-in property handlers with File Meta. Presumably, properties that could be written to the file format would be handled by the built-in property handler, while properties that the file format could not handle and therefore produced write errors would be written by File Meta. This leads to a situation in which properties are held in disjoint stores, and potentially to unexpected outcomes, e.g. if the file were e-mailed as an attachment, some properties would be preserved, and some would not. I'm not sure how this could be worked around.

May 6, 2014 at 10:13 PM
Edited May 6, 2014 at 10:15 PM
Hey Dijji,

Thanks for v1.2.

Emailing doesn't preserve ADSes also with FileMeta by itself, so it's not a big difference. But considering it's anyway a power-user feature, the sender or receiver will be aware of it. If they want to preserve that data they are likely to know what to do (RAR it up keeping ADSes, export/import, etc.).

My usage of FileMeta is just for file comments. I definitely don't want the comments to modify the file, even if a native handler supported that. My potential use of chaining would just be to view meta data of certain file formats (mostly media), which would otherwise require a 3rd party software.

Other people may have different goals, so a property handler chainer could have an option to control the handler precedence. And if custom properties are supported by Windows, another option could be to remap conflicting properties to something unique under a FileMeta group (assuming it's possible).