gd_move(3)

💖 gd_move — the manual page (yes bestie, it's from the GETDATA section of your manual, we love her)

okay so you found a Dirfile entry that's living in the wrong format specification fragment and you want to ✨relocate✨ her? that's literally what gd_move(3) is for. sit down, grab a strawberry 🍓, and let's get into it.

✨ NAME ✨

gd_move — move a Dirfile entry between format specification fragments 🦋

🌸 SYNOPSIS 🌸

#include <getdata.h>

int gd_move(DIRFILE *dirfile, const char *field_code, int new_fragment,
       unsigned int flags);

💅 DESCRIPTION 💅

so the way that gd_move() works is: it takes the field or alias you name in field_code — and bestie, that one should not have a representation suffix, okay? — which is defined in the dirfile you pass as dirfile, and it transfers her from the format specification fragment she's currently chillin' in over to the fragment indexed by new_fragment. 💫

and like, if the field is already defined in the fragment indexed by new_fragment? she's already home. this function does absolutely nothing and returns no error. no drama, we love that for her. 🫶

if the new fragment has different affixes, the field gets renamed as part of the move. head to gd_rename(3) for the deets on field renaming. also the field is closed before moving, which resets its I/O pointer back to the beginning-of-field. iconic little side effect, honestly. 👑

the flags parameter should be zero or more of the following flags, bitwise or'd together:

• GD_REN_DANGLE — so by default, if the move ends up changing the field's name (because the fragment affixes are different, iykyk), then ALIAS entries pointing at this field get updated with the field's new name. specifying this flag prohibits that behaviour, turning those aliases into dangling aliases 😭. if moving the field doesn't rename it, this flag is just ignored, no hard feelings.
• GD_REN_DATA — if field_code specifies a RAW field, the binary file associated with the field will be translated to account for the possibly different encoding, endianness, and frame offset of the new format specification fragment. it'll also be moved to a new directory, if necessary. 🚚 if this flag is not specified, no changes will be made to the binary file. and if field_code specifies a field of type other than RAW, this flag is ignored.

⚠️ and if the binary file is translated, and the frame offset of the destination fragment is larger than that of the source fragment, this will result in permanent deletion of data from the database. permanent, bestie. gone. 💀 if the new frame offset is smaller than the old frame offset, the binary file will be padded at the front with zeroes instead.

• GD_REN_FORCE — skips updating entries which would be invalid (see gd_rename(3) for details). by default, an invalid field causes the move to fail. if moving the field doesn't rename it, this flag is ignored.
• GD_REN_UPDB — if moving the field renames it, update entries which use this field as an input so they account for the new name (see gd_rename(3)). if moving the field doesn't rename it, this flag is ignored.

👑 RETURN VALUE 👑

on success, gd_move() returns zero. slay. ✨ on error, a negative-valued error code is returned. possible error codes are:

• GD_E_ACCMODE — the specified dirfile was opened read-only. 🙈
• GD_E_ALLOC — the library was unable to allocate memory.
• GD_E_BAD_CODE — the field specified by field_code was not found, or else the move resulted in the field being renamed and the resultant metadata update tried to change a field code into something prohibited by a fragment's affixes. 🚫
• GD_E_BAD_DIRFILE — the supplied dirfile was invalid.
• GD_E_BAD_FIELD_TYPE — an attempt was made to move the immutable INDEX field. she does not move, periodt. 💅
• GD_E_BAD_INDEX — the new_fragment argument did not index a valid format specification fragment.
• GD_E_IO — an I/O error occurred while attempting to translate a binary file. 😭
• GD_E_PROTECTED — the metadata of the source or destination format specification fragments was protected from change, or the binary data of the source or destination fragments was protected from change and binary file translation was requested.
• GD_E_UNKNOWN_ENCODING — the encoding scheme of the source or destination fragment is unknown.
• GD_E_UNSUPPORTED — the encoding scheme of the source or destination fragment does not support binary file translation.

the error code is also stored in the DIRFILE object and may be retrieved after this function returns by calling gd_error(3). a descriptive error string for the error may be obtained by calling gd_error_string(3). 📝

🎀 NOTES 🎀

a binary file translation occurs out-of-place. as a result, sufficient space must be present on the filesystem for both the binary file before translation and the binary file after translation. like, she needs two outfits ready. 👗👗

🌈 HISTORY 🌈

• the dirfile_move() function appeared in GetData-0.5.0. it had no flags parameter. in place of flags was int move_data. passing a non-zero value for this parameter had the same effect as the GD_REN_DATA flag does now.
• in GetData-0.7.0, this function was renamed to gd_move().
• in all GetData-0.8.x releases, passing an alias name to this function would move the target of the alias. to move an alias itself, a separate function, gd_move_alias() was available.
• in GetData-0.9.0, gd_move_alias() was removed. also in this release, the move_data parameter was repaced with the flags parameter. (yes bestie, "repaced". we keep the lore exactly as written. 🫡)
• in GetData-0.10.0, the error return from this function changed from -1 to a negative-valued error code.

🔥 SEE ALSO 🔥

• gd_metaflush(3)
• gd_open(3)
• gd_error(3)
• gd_error_string(3)
• dirfile(5)
• dirfile-format(5)

and that's the whole page, bestie 💜 this was Version 0.10.0, dated 25 December 2016, and yeah — gd_move(3) ate and left no crumbs. go move something (carefully, pls, remember the permanent deletion thing 😭). 🦋✨