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

Where is FileMeta.exe??

May 12, 2014 at 5:00 PM
FileMeta.exe command line tool is described in the documentation, but it does not seem to be included with the standard binary installation package.
May 13, 2014 at 7:51 AM
Hi ronco

This will be clearer when File Meta 1.2 becomes the recommended release, shortly.

For File Meta 1.1, the command line support is available as a separate beta download. For File Meta 1.2, command line support is part of the standard package. In both cases, filemeta.exe is installed in the program files folder File Metadata, though the beta was x86 only.

Hope this helps.

Jun 17, 2014 at 12:07 AM
Thanks for the reply. I just installed version 1.2 and everything seems to work as intended.

I'd just like to mention a couple things that caused me some confusion that might be useful to include in a FAQ or Troubleshooting doc.

First, when using FileMeta with Microsoft's Windows Explorer, the metadata is handled exactly as documented and it allows you to do some nice things like sorting a list of files by Title or Tags. However, none of the 3rd party file managers I tried handles the metadata properly. So, I was under the impression that FileMeta wasn't working right, but it was just the file manager I was using. Like many people, I don't really care much for Windows Explorer. Are you aware of any free file manager that enables the use of metadata for all file types?

Second, the text editor I use blows away the metadata when saving a file. I did see that this is documented. I'll try changing the editor settings to update the file inplace.

When there is a hardlinked file, you don't see the metadata for the file it's linked to and you get an error if you try to add metadata. It would be great if the metadata could be shared somehow. But, if that can't be done, it might be advisable to document the limitation.

You'd think that with all the money Bill Gates has, he'd be able to hire somebody to make metadata work for all file types. But, I digress. Thanks for a great product.
Jun 17, 2014 at 12:19 PM
Edited Jun 17, 2014 at 12:25 PM
Hi ronco,

I do not know of any such third party File Manager. However, this is not saying very much since I have very little experience with alternatives to Explorer. It is a shame if alternative File Managers do not exploit the property system: it defines more than 2600 properties and their associated metadata, and makes them all accessible through a reasonably straightforward API. Though, of course, how most of these properties are stored is not defined by out-of-the-box Windows for most file types, hence File Meta. If I discover (or anybody can point out) a third-party File Manager that does respect properties, I will mention it in the documentation.

On the links, I'm not experiencing the same problems as you are. On my Windows 7 system, Windows Explorer shows and allows the editing of metadata properties for both hard links and symbolic links (to avoid any ambiguity, I mean the links created using mklink, and you do have to give the link a name with the same extension as the linked file to make it work). Changes are reflected, as you would expect, both on the original file and other links to the file.

I'm glad that you're finding my efforts useful!

Jun 18, 2014 at 2:01 AM
Edited Jun 18, 2014 at 2:06 AM
I tried the link again. I associated .txt and .htm to the Simple profile. I linked source.txt to target.txt and the metadata was shared. I removed source.txt and target.txt. I created source.txt and linked it to target.htm. The metadata did not share to target.htm. And an error occurred when I tried adding metadata to target.htm. So, it seems to be a problem only when the extension is different.

I used the Windows port of the Linux ln command to do the links (ln -T source target). It's part of the coreutils for Windows package. I think it works the same as mklink but I'm not sure of that.

I see that you mentioned that the extension has to be the same for it to function properly. Is there any chance this limitation could be worked around as long as the profile of editable properties is the same?
Jun 18, 2014 at 8:40 AM
Intriguing. I took a target .txt file, and created a link to it with a.pdf extension (.txt and.pdf are both set up to use the File Meta property handler), and metadata read and write work correctly. A link with a .txt extension to a .pdf file also works fine.

Profile does not seem to matter. In these tests, .txt, was configured with the simple profile and .pdf the Office profile. I was able to update even properties on the .txt file that are not in the simple profile (e.g. content type) using a .pdf link without a problem. This is not surprising, as the profile controls what properties Explorer displays, but is not referenced at any deeper level.

The only thing that seems to be important is that the extensions of the source and target are both set up to use the File Meta property handler.

I wonder if this is about using mklink? Could you give that a try?
Jun 19, 2014 at 2:08 AM
I did try mklink, and the link between .txt and .htm is working as expected now. The only little glitch is that Windows Explorer doesn't show all the same metadata for .txt and .htm.

I changed my text editor preferences so that it updates inplace when saving. And the metadata still disappears. I tired a simpler experiment.

echo xyz >>file.txt <== append to the file and the metadata is preserved

echo xyz >file.txt <== overwrite the file and the metadata is gone
Jun 19, 2014 at 10:17 AM
I am glad that mklink addresses your issues with links. As far as I know, which properties are shown in Explorer is controlled entirely by the profile chosen for the extension, so to show the same properties for .txt and .htm, they should have the same profile.

The issue of loss of metadata when a file is edited is an important limitation of File Meta. And, as your editor and echo test demonstrate, it is not always easy to predict which actions are updates, and therefore metadata preserving, and which recreate the file, and therefore lose metadata. The only defence that I know of is to backup the metadata to XML, either for each file, or in bulk using the command line utility.