BAppFileInfo lets you get and set the signature, supported types, icons, app flags, and version info that's stored in an executable file's attributes and/or resources. The object also knows how to write certain particles of information into the File Type database and, if the executable is the progenitor of a running application, into the app roster (be_roster).


Most apps won't ever need to create or use a BAppFileInfo object. Setting an executable's info is best left to the file's creator, through the use of resource data that's compiled into the executable. Even the act of looking at a file's info should be rare for a normal application.


BAppFileInfo objects should only be used to examine and set the characteristics of applications and add-ons. Using the object on a non-executable file could corrupt the file.


You initialize a BAppFileInfo object by passing it a BFile object that represents an application or add-on. The BFile needn't be open for reading, but it must be open for writing if you want to set information. The BAppFileInfo object doesn't take over ownership of the BFile that you pass it; in particular, deleting a BAppFileInfo doesn't cause the underlying BFile to be deleted.

To initialize a BAppFileInfo to point to the executable of be_app, you do this:

/* To get app file info for be_app. */
app_info appInfo;
BFile file;
BAppFileInfo appFileInfo;

file.SetTo(&appInfo.ref, B_READ_WRITE);

Attributes, Resources, and the File Type Database

When you ask a BAppFileInfo object to get some information, it looks in its BFile's attributes; if the information isn't there, it then looks in the file's resources. When you ask it to set some information, the info is written as an attribute and also stored as a resource. You can modify this behavior through SetInfoLocation(): You can tell the object to only access the file's attributes, or to only access the resources.

The signature, icons, and supported types that you set through the functions provided here ( SetSignature(), SetIcon(), SetIconForType(), SetSupportedTypes()) are also recorded in the File Types database, as described in the various functions.

Functions Inherited From BNodeInfo

You should take care when using the following functions (inherited from BNodeInfo):


Never set an application's preferred app; an application is automatically set to be its own preferred app—it won't work otherwise. An add-on's preferred app is usually itself, but it doesn't have to be. For example, you could set an add-on's preferred app to be the server or application that loads the add-on.


Never set the type of an application or add-on. The type is automatically set to be B_APP_MIME_TYPE (a platform-dependent value). If you change the type, your application or add-on will still run (probably), but other parts of the system (double-clicked documents, for example) may have a hard time finding it.


When you ask a BAppFileInfo to retrieve information by reference, the object doesn't clear the reference argument if it fails. Because of this, you should always check the error code that's returned by the Get…() functions.

The common errors that BAppFileInfo functions return are these:





The BAppFileInfo is uninitialized, or its BFile isn't open for writing.


The BFile was locked when you initialized the BAppFileInfo.

The info-reading and -writing functions may also return the error codes declared by BNode::ReadAttr() and BNode::WriteAttr() , and by BResources::WriteTo().

Creative Commons License
Legal Notice
This work is licensed under a Creative Commons Attribution-Non commercial-No Derivative Works 3.0 License.