.TH "Key :: Meta Info Manipulation Methods" 3 "Fri Aug 26 2011" "Elektra Projekt" \" -*- nroff -*- .ad l .nh .SH NAME Key :: Meta Info Manipulation Methods \- .PP Methods to do various operations on Key metainfo. .SS "Functions" .in +1c .ti -1c .RI "int \fBkeyStat\fP (Key *key)" .br .ti -1c .RI "int \fBkeyRemove\fP (Key *key)" .br .ti -1c .RI "uid_t \fBkeyGetUID\fP (const Key *key)" .br .ti -1c .RI "int \fBkeySetUID\fP (Key *key, uid_t uid)" .br .ti -1c .RI "gid_t \fBkeyGetGID\fP (const Key *key)" .br .ti -1c .RI "int \fBkeySetGID\fP (Key *key, gid_t gid)" .br .ti -1c .RI "int \fBkeySetDir\fP (Key *key)" .br .ti -1c .RI "mode_t \fBkeyGetMode\fP (const Key *key)" .br .ti -1c .RI "int \fBkeySetMode\fP (Key *key, mode_t mode)" .br .ti -1c .RI "type_t \fBkeyGetType\fP (const Key *key)" .br .ti -1c .RI "int \fBkeySetType\fP (Key *key, type_t newType)" .br .ti -1c .RI "time_t \fBkeyGetATime\fP (const Key *key)" .br .ti -1c .RI "int \fBkeySetATime\fP (Key *key, time_t atime)" .br .ti -1c .RI "time_t \fBkeyGetMTime\fP (const Key *key)" .br .ti -1c .RI "int \fBkeySetMTime\fP (Key *key, time_t mtime)" .br .ti -1c .RI "time_t \fBkeyGetCTime\fP (const Key *key)" .br .ti -1c .RI "int \fBkeySetCTime\fP (Key *key, time_t ctime)" .br .in -1c .SH "Detailed Description" .PP Methods to do various operations on Key metainfo. To use them: .PP .nf #include .fi .PP .PP Next to \fBName (key and owner) \fP and \fBValue (data and comment) \fP there is the so called metainfo inside every key. .PP Key metainfo insists of: .IP "\(bu" 2 UID, the user id .IP "\(bu" 2 GID, the group id .IP "\(bu" 2 filesystem-like mode permissions (rwx) .IP "\(bu" 2 Mode, change and modification times .PP .PP The comment can contain userdata which directly belong to that key. .PP Owner is the user that owns the key. It only works for the user/ hierarchy. .PP Every user and group of your System has a uniqe ID. These values are used in the keys too. They are very important for the mode. See man 2 chown. .PP With the mode mode you can choose if a user, group or the world can mode your key. See man 2 chmod. .SH "Function Documentation" .PP .SS "time_t keyGetATime (const Key *key)"Get last time the key data was read from disk. .PP Every \fBkdbGet()\fP might update the access time of a key. You get information when the key was read the last time from the database. .PP You will get 0 when the key was not read already. .PP Beware that multiple copies of keys with \fBkeyDup()\fP might have different atimes because you \fBkdbGet()\fP one, but not the other. You can use this information to decide which key is the latest. .PP \fBParameters:\fP .RS 4 \fIkey\fP Key to get information from. .RE .PP \fBReturns:\fP .RS 4 the time you got the key with \fBkdbGet()\fP .PP 0 on key that was never \fBkdbGet()\fP .PP (time_t)-1 on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeySetATime()\fP .PP \fBkdbGet()\fP .RE .PP .SS "time_t keyGetCTime (const Key *key)"Get last time the key metadata was changed from disk. .PP You will get 0 when the key was not read already. .PP Any changed field in metadata will influence the ctime of a key. .PP This time is not updated if only value or comment are changed. .PP Not changed keys will not update this time, even after \fBkdbSet()\fP. .PP It is possible that other keys written to disc influence this time if the backend is not grained enough. .PP \fBParameters:\fP .RS 4 \fIkey\fP Key to get information from. .RE .PP \fBSee also:\fP .RS 4 \fBkeySetCTime()\fP .RE .PP \fBReturns:\fP .RS 4 (time_t)-1 on NULL pointer .PP the metadata change time .RE .PP .SS "gid_t keyGetGID (const Key *key)"Get the group ID of a key. .SH "GID" .PP The group ID is a unique identification for every group present on a system. Keys will belong to root (0) as long as you did not get their real GID with \fBkdbGet()\fP. .PP Unlike UID users might change their group. This makes it possible to share configuration between some users. .PP A fresh key will have (gid_t)-1 also known as the group nogroup. It means that the key is not related to a group ID at the moment. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 the system's GID of the key .PP (gid_t)-1 on NULL key or currently unknown ID .RE .PP \fBSee also:\fP .RS 4 \fBkeySetGID()\fP, \fBkeyGetUID()\fP .RE .PP .SS "mode_t keyGetMode (const Key *key)"Return the key mode permissions. .PP Default is 0664 (octal) for keys and 0775 for directory keys which used \fBkeySetDir()\fP. .PP The defaults are defined with the macros KEY_DEF_MODE and KEY_DEF_DIR. .PP For more information about the mode permissions see \fBMode\fP. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 mode permissions of the key .PP (mode_t)-1 on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeySetMode()\fP .RE .PP .SS "time_t keyGetMTime (const Key *key)"Get last modification time of the key on disk. .PP You will get 0 when the key was not read already. .PP Everytime you change value or comment and \fBkdbSet()\fP the key the mtime will be updated. When you \fBkdbGet()\fP the key, the atime is set appropriate. .PP Not changed keys may not even passed to \fBkdbSet_backend()\fP so it will not update this time, even after \fBkdbSet()\fP. .PP It is possible that other keys written to disc influence this time if the backend is not grained enough. .PP If you add or remove a key the key thereunder in the hierarchy will update the mtime if written with \fBkdbSet()\fP to disc. .PP \fBParameters:\fP .RS 4 \fIkey\fP Key to get information from. .RE .PP \fBSee also:\fP .RS 4 \fBkeySetMTime()\fP .RE .PP \fBReturns:\fP .RS 4 the last modification time .PP (time_t)-1 on NULL pointer .RE .PP .SS "type_t keyGetType (const Key *key)"Returns the key data type. .PP See #type_t for the type definition. .PP \fBSee also:\fP .RS 4 \fBkeySetType()\fP .PP \fBkeyIsBinary()\fP and \fBkeyIsString()\fP .PP \fBkeyIsDir()\fP is not related to the type system .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP key where to get the type. .RE .PP \fBReturns:\fP .RS 4 the key type .PP KEY_TYPE_UNDEFINED on keys without type .PP -1 on NULL pointer .RE .PP .SS "uid_t keyGetUID (const Key *key)"Get the user ID of a key. .SH "UID" .PP The user ID is a unique identification for every user present on a system. Keys will belong to root (0) as long as you did not get their real UID with \fBkdbGet()\fP. .PP Although usually the same, the UID of a key is not related to its owner. .PP A fresh key will have (uid_t)-1 also known as the user nobody. It means that the key is not related to a user ID at the moment. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 the system's UID of the key .PP (uid_t)-1 on NULL key or currently unknown ID .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetGID()\fP, \fBkeySetUID()\fP, \fBkeyGetOwner()\fP .RE .PP .SS "int keyRemove (Key *key)"Permanently remove a key after committing to database. .PP This functions sets a flag that the key needs to be removed. It also sets a flag that it is not synced. .PP Remove the key instead of writing it in the key database when doing \fBkdbSet()\fP and related functions. .PP This key will be ignored and it is save to delete it afterwards. To be sure that it was removed, check if it needs sync with \fBkeyNeedSync()\fP. .PP \fBNote:\fP .RS 4 Delete in elektra terminology means to free memory, remove means to free permanent storage. .RE .PP \fBWarning:\fP .RS 4 You should not change a key's remove status once it belongs to a keyset. See \fBksSort()\fP for more information. .RE .PP \fBSee also:\fP .RS 4 \fBkeyNeedRemove()\fP, \fBkdbSet()\fP, \fBkdbRemove()\fP .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 1 on success .PP -1 on NULL pointer .RE .PP .SS "int keySetATime (Key *key, time_tatime)"Update the atime information for a key. .PP When you do manual sync of keys you might also update the atime to make them indistinguishable. .PP It can also be useful if you work with keys not using a keydatabase. .PP \fBParameters:\fP .RS 4 \fIkey\fP The Key object to work with .br \fIatime\fP The new access time for the key .RE .PP \fBReturns:\fP .RS 4 0 on success .PP -1 on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetATime()\fP .RE .PP .SS "int keySetCTime (Key *key, time_tctime)"Update the ctime information for a key. .PP \fBParameters:\fP .RS 4 \fIkey\fP The Key object to work with .br \fIctime\fP The new change metadata time for the key .RE .PP \fBReturns:\fP .RS 4 0 on success .PP -1 on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetCTime()\fP .RE .PP .SS "int keySetDir (Key *key)"Set mode so that key will be recognized as directory. .PP The function will add all executable bits. .PP .IP "\(bu" 2 Mode 0200 will be translated to 0311 .IP "\(bu" 2 Mode 0400 will be translated to 0711 .IP "\(bu" 2 Mode 0664 will be translated to 0775 .PP .PP The macro KEY_DEF_DIR (defined to 0111) will be used for that. .PP The executable bits show that child keys are allowed and listable. There is no way to have child keys which are not listable for anyone, but it is possible to restrict listing the keys to the owner only. .PP .IP "\(bu" 2 Mode 0000 means that it is a key not read or writable to anyone. .IP "\(bu" 2 Mode 0111 means that it is a directory not read or writable to anyone. But it is recognized as directory to anyone. .PP .PP For more about mode see \fBkeySetMode()\fP. .PP It is not possible to access keys below a not executable key. If a key is not writeable and executable \fBkdbSet()\fP will fail to access the keys below. If a key is not readable and executable \fBkdbGet()\fP will fail to access the keys below. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key to set permissions to be recognized as directory. .RE .PP \fBReturns:\fP .RS 4 0 on success .PP -1 on NULL pointer .RE .PP \fBSee also:\fP .RS 4 \fBkeySetMode()\fP .RE .PP .SS "int keySetGID (Key *key, gid_tgid)"Set the group ID of a key. .PP See \fBGID\fP for more information about group IDs. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .br \fIgid\fP is the group ID .RE .PP \fBReturns:\fP .RS 4 0 on success .PP -1 on NULL key .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetGID()\fP, \fBkeySetUID()\fP .RE .PP .SS "int keySetMode (Key *key, mode_tmode)"Set the key mode permissions. .PP The mode consists of 9 individual bits for mode permissions. In the following explanation the octal notation with leading zero will be used. .PP Default is 0664 (octal) for keys and 0775 for directory keys which used \fBkeySetDir()\fP. .PP The defaults are defined with the macros KEY_DEF_MODE and KEY_DEF_DIR. .PP \fBNote:\fP .RS 4 libelektra 0.7.0 only allows 0775 (directory keys) and 0664 (other keys). More will be added later in a sense of the description below. .RE .PP .SH "Mode" .PP 0000 is the most restrictive mode. No user might read, write or execute the key. .PP Reading the key means to get the value and comment by \fBkdbGet()\fP or all highlevel methods. .PP Writing the key means to set the value and comment by \fBkdbSet()\fP or all highlevel methods. .PP Execute the key means to make a step deeper in the hierarchy. But you must be able to read the key to be able to list the keys below. See also \fBkeySetDir()\fP in that context. But you must be able to write the key to be able to add or remove keys below. .PP 0777 is the most relaxing mode. Every user is allowed to read, write and execute the key, if he is allowed to execute and read all keys below. .PP 0700 allows every action for the current user, identified by the uid. See \fBkeyGetUID()\fP and \fBkeySetUID()\fP. .PP To be more specific for the user the single bits can elect the mode for read, write and execute. 0100 only allows executing which gives the information that it is a directory for that user, but not accessible. 0200 only allows reading. This information may be combined to 0300, which allows execute and reading of the directory. Last 0400 decides about the writing permissions. .PP The same as above is also valid for the 2 other octal digits. 0070 decides about the group permissions, in that case full access. Groups are identified by the gid. See \fBkeyGetGID()\fP and \fBkeySetGID()\fP. In that example everyone with a different uid, but the gid of the the key, has full access. .PP 0007 decides about the world permissions. This is taken into account when neighter the uid nor the gid matches. So that example would allow everyone with a different uid and gid of that key gains full access. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key to set mode permissions .br \fImode\fP the mode permissions .RE .PP \fBReturns:\fP .RS 4 0 on success .PP -1 on NULL key .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetMode()\fP .RE .PP .SS "int keySetMTime (Key *key, time_tmtime)"Update the mtime information for a key. .PP \fBParameters:\fP .RS 4 \fIkey\fP The Key object to work with .br \fImtime\fP The new modification time for the key .RE .PP \fBReturns:\fP .RS 4 0 on success .RE .PP \fBSee also:\fP .RS 4 \fBkeyGetMTime()\fP .RE .PP .SS "int keySetType (Key *key, type_tnewType)"Set a new key type. .PP This method is usually not needed, unless you are working with more semantic value types, or want to force a specific value type for a key. It is not usually needed because the data type is automatically set when setting the key value. .PP See #type_t for the type defintion. .PP \fBExample:\fP .RS 4 .PP .nf // here we define the new type enum { KEY_TYPE_COLOR=KEY_TYPE_STRING+4 }; // here we make a new key with the type Key *k1 = keyNew ('user/sw/oyranos/current/color1', KEY_VALUE, '#4B52CA', KEY_COMMENT, 'a custom color', KEY_TYPE, KEY_TYPE_COLOR, KEY_END); // lets check if it is really correct type if (keyGetType(k1) == KEY_TYPE_COLOR) printf ('correct type'); .fi .PP .RE .PP When using type_t::KEY_TYPE_DIR, this method will not set mode permissions to the key. You'll have to set it manually after \fBkeySetType()\fP, calling \fBkeySetMode()\fP with appropriate permissions. Or use the \fBkeySetDir()\fP. .PP \fBSee also:\fP .RS 4 \fBkeyGetType()\fP .PP \fBkeySetDir()\fP to see that the directory concept is independent of types .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .br \fInewType\fP contains the new type .RE .PP \fBReturns:\fP .RS 4 0 on sucess .PP -1 on NULL pointer and when newType >= KEY_TYPE_MAX .RE .PP .SS "int keySetUID (Key *key, uid_tuid)"Set the user ID of a key. .PP See \fBUID\fP for more information about user IDs. .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .br \fIuid\fP the user ID to set .RE .PP \fBReturns:\fP .RS 4 0 on success .PP -1 on NULL key .RE .PP \fBSee also:\fP .RS 4 \fBkeySetGID()\fP, \fBkeyGetUID()\fP, \fBkeyGetOwner()\fP .RE .PP .SS "int keyStat (Key *key)"Only stat a key instead of receiving value, comment and key type. .PP Only stat the key in the database when doing \fBkdbGet()\fP. The key may not have any value, comment or key type set. .PP It is not possible to revert the action on per-key basis. When you want to remove the flag you have to pass option_t::KDB_O_NOSTAT to the next \fBkdbGet()\fP. .PP \fBSee also:\fP .RS 4 \fBkeyNeedStat()\fP, \fBkdbGet()\fP .RE .PP \fBParameters:\fP .RS 4 \fIkey\fP the key object to work with .RE .PP \fBReturns:\fP .RS 4 1 on succuess .PP -1 on NULL pointer .RE .PP .SH "Author" .PP Generated automatically by Doxygen for Elektra Projekt from the source code.