Products like Picasa build databases that include metadata about files. Captions, keywords locations and the like.
Files have a number of attributes that is dependant on the file type and / or the application that produced the file.
My question is can I programmatically add a tag to a file and then use this tag to search for content.
Eg. Text files include Name, Type, Folder Path, Size, Date Created, Date Modified, Attributes, Owner, Computer. How can I add a "Keywords" attribute?
I am interested in a solution in C# but am primarily asking for help in understanding how this functionality could be implemented in Windows operating systems.
Thank you
You can try to use Extended Attributes, but they don't have a good API in Windows and in general are not widely used. There also exist Alternate Data Streams, but these are ,as the name suggests, data streams, and not attributes.
Related
In the docs for FieldMask the paths use the field names (e.g., foo.bar.buzz), which means renaming the message field names can result in a breaking change.
Why doesn't FieldMask use the field numbers to define the path?
Something like 1.3.1?
You may want to consider filing an issue on the GitHub protocolbuffers repo for a definitive answer from the code's authors.
Your proposal seems logical. Using names may be a historical artifact. There's a possibly relevant comment on an issue thread in that repo:
https://github.com/protocolbuffers/protobuf/issues/3793#issuecomment-339734117
"You are right that if you use FieldMasks then you can't safely rename fields. But for that matter, if you use the JSON format or text format then you have the same issue that field names are significant and can't be changed easily. Changing field names really only works if you use the binary format only and avoid FieldMasks."
The answer for your question lies in the fact FieldMasks are a convention/utility developed on top of the proto3 schema definition language, and not a feature of it (and that utility is not present in all of the language bindings)
While you’re right in your observation that it can break easily (as schemas tend evolve and change), you need to consider this design choice from a user friendliness POV:
If you’re building an API and want to allow the user to select the field set present inside the response payload (the common use case for field masks), it’ll be much more convenient for you to allow that using field paths, rather then binary fields indices, as the latter would force the user of the gRPC/protocol generated code to be “aware” of the schema. That’s not always the desired case when providing API as a code software packages.
While implementing this as a proto schema feature can allow the user to have the best of both worlds (specify field paths, have them encoded as binary indices) for binary encoding, it would also:
Complicate code generation requirements
Still be an issue for plain text encoding.
So, you can understand why it was left as an “external utility”.
I have created a certificate design with powerpoint.
Now I have to create 100+ copies of it... each with a different name (the recipent).
I was wondering if there was an easy way to do it...
I can have the list of names in excel or txt.
I am open to other ideas as well, like changing the slide into an images and batch processing it in a simple way
You may also try out SlideMight, a tool for merging hierarchical data with PowerPoint templates. SlideMight supports iteration over data, to generate slides or to populate tables. There is more functionality, but you don't seem to need that. SlideMight is in fact a coding system, like mail merge for Word is.
Input data format is at this time just JSON; you would need to convert your Excel sheets first, e.g. using this Excel to JSON add-in for Excel.
There are versions for Windows and Mac OS X.
More information is at www.SlideMight.com
Disclaimer:
I am the owner of Delftware Technology, the company that developed SlideMight.
And I am one of the developers.
This is a question that really belongs in SuperUser, not StackOverflow (which is intended for coding questions, not software how-to-use questions).
But ...
Save your names to a plain notepad TXT file, one name per line.
Start PowerPoint, choose File, Open and point to your TXT file (you may force the matter by choosing . in Files of type:
Apply whatever template you like to the result.
I have a commercial add-in that'll do this and quite a bit more, but from your description, you don't need it.
In Windows Explorer a file has three dates: "creation date", "last modified date" and "acquisition date?" (in Italian it is called "data acquisizione". It is important for me because it is the exact date at which, e.g., a photo is taken (the other two dates change upon trasmission, e.g. when sending zipped files. I know functions to get "creation date" and "last modified date", but I do not how to get the "acquisition date?" of a file. Can you help me? All the best, Ovidio Crocicchi
You are trying to obtain a metadata that is only contained in image files, like JPEG.
I had the same problem and I have not found a solution using standard API. Eventually I solve the problem using the metadata-extractor library that can extract EXIF metadata from image files. The library is really user-friendly, this is the code I used:
File file = new File("C:\\myFile.jpg");
Metadata metadata = ImageMetadataReader.readMetadata(file);
Date acquisitionDate = metadata.getDirectory(ExifIFD0Directory.class)
.getDate(ExifIFD0Directory.TAG_DATETIME);
Windows files have 3 file times, all are exposed in the windows API.
Creation Date, Modified Date, Last Accessed Date.
Any other date is an extended property.
There are S/O articles on reading and setting extended properities via C# using the .net framework.
You should also be able to right click on a file in explorer, select properties from the context menu and see all of the extended properties -- c.f. the MS article Retrieving Extended File Properties
ADDED
You mention that these attributes are not copied when the file is copied. This is a very common problem with these extended attribute as many programs do not copy these extended properties when copying a file because they are only loosely coupled to the file and are not copied automatically whenever the file is copied -- as such, they should not rely on them to store important information, and because of this, they are likely to be poorly supported essentially forever -- since programmers won't rely upon them for important information.
Depending upon the target filesystem, there may be no way to copy these extended attributes at all. E.g. drives using FAT32 (common for USB drives).
Our application (rewritten to wxWidgets) should use mostly common strings from the language catalogs (.mo). But it also uses panels with texts that are tailored for the customer via the configuration file. The configuration files are generated for the customer, so it could be (say) another catalog file. However...
Can one catalog file contain replacements (overwrites) for the default strings from the basic catalog?
Or, can the structure with strings loaded from the catalogs (.mo) be modified programmatically? (I mean if it can be done using some recommended way in the sense "Don't pee against the wind".)
Is there any standardized mechanism for storing the user-defined strings (via the same application)?
Thanks for your time and experience,
Petr
You can load several catalog files by using wxLocale::AddCatalog. The translations are searched for in all the catalogs loaded. If two catalogs contain the same string, I assume the translation is taken from the catalog that was loaded first. I didn't test though, admittedly. Anyway, if this is the case, you need to make sure the custom catalog file is loaded first. That way the translations in the custom catalog have precedence, and effectively they replace the default translations.
We're creating an app that is going to generate some text files on *nix systems with hashed filenames to avoid too-long filenames.
However, it would be nice to tag the files with some metadata that gives a better clue as to what their content is.
Hence my question. Does anyone have any experience with creating files with custom metadata in Ruby?
I've done some searching and there seem to be some (very old) gems that read metadata:
https://github.com/kig/metadata
http://oai.rubyforge.org/
I also found: system file, read write o create custom metadata or attributes extended which seems to suggest that what I need may be at the system level, but dropping down there feels dirty and scary.
Anyone know of libraries that could achieve this? How would one create custom metadata for files generated by Ruby?
A very old but interesting question with no answers!
In order for a file to contain metadata, it has to have a format that has some way (implicitly or explicitly) to describe where and how the metadata is stored.
This can be done by the format, such as having a header that says where the "main" data is stored and where the "metadata" is stored, or perhaps implicitly, such as having a length to the "main" data, and storing metadata as anything beyond the "main" data.
This can also be done by the OS/filesystem by storing information along with the files, such as permission info, modtime, user, and more comprehensive file information like "icon" as you would find with iOS/Windows.
(Note that I am using "quotes" around "main" and "metadata" because the reality is that it's all data, and needs to be stored in some way that tools can retrieve it)
A true text file does not contain any headers or any such file format, and is essentially just a continuous block of characters (disregarding how the OS may store it). This also means that it can be generally opened by any text editor, which will merely read and display all the characters it finds.
So the answer in some sense is that you can't, at least not on a true text file that is truly portable to multiple OS.
A few thoughts on how to get around this:
Use binary at the end of the text file with hope/requirements that their text editor will ignore non-ascii.
Store it in the OS metadata for the file and make it OS specific (such as storing it in the "comments" section that an OS may have for a file.
Store it in a separate file that goes "along with" the file (i.e., file.txt and file.meta) and hope that they keep the files together.
Store it in a separate file and zip the text and the meta file together and have your tool be zip aware.
Come up with a new file format that is not just text but has a text section (though then it can no longer be edited with a text editor).
Store the metadata at the end of the text file in a text format with perhaps comments or some indicator to leave the metadata alone. This is similar to the technique that the vi/vim text editor uses to embed vim commands into a file, it just puts them as comments at the beginning or end of the file.
I'm not sure there are many other ways to accomplish what you want, but perhaps one of those will work.