jf_file_open and
jf_journal_open?
fsync and
jf_journal_commit?
2.1. Can I use relative paths instead of absolute paths when opening
journaled files and journals with functions
jf_file_open and
jf_journal_open?
Yes, you may, but some precautions must be taken: when you re-use a journaled file created using a relative path you must start your program from the same current dir of creation time because journal file keeps original relative path. Some issues may happen if you have symbolic link in your path. As a general rule, it's strongly suggested to use absolute paths if journal file and related journaled files are not stored in the same directory.
Commands:
strings /opt/libjf/lib/libjf | grep 'feature/'retrieve which features are active in compiled library.
Compile a linked_proj_record.xml record and send
to <tiian@users.sourceforge.net>
2.4. I would like to port libjf to some different operating system, will you merge my fixes & patches?
After revision, your porting fixes and patches will be merged in main distribution and you will be cited as a contributor. A specific forum has been created on SourceForge.net for porting related discussions.
Yes, you may, but libjf objects are not multi-thread self protected: it's your responsibility avoid the same set of objects (a journal and its related journaled files) is accessed at the same time by two or more threads. At this time the support is guaranteed only by reentrant code: there is no static variable with a little exception can be ignored in most cases (it's a trivial counter used only when --enable-crash-simul build option is active).
Your application must set
recovery_enabled =
TRUE
in jf_journal_opts_s struct passed to
jf_journal_open function.
This type of recovery is called "automatic recovery"
and is not enabled by default (you must set it).
Sometimes, the crash may damage the journal itself, but some errors
can be fixed with a "forced recovery".
Your application must set
recovery_enabled =
TRUE and
recovery_damaged_journal =
TRUE
in jf_journal_opts_s struct passed to
jf_journal_open function.
This type of recovery is called
"automatic forced recovery" and is not
enabled by default (you must set it).
Yes, libjf supports binary files as well as text files, but there are some differences between standard ANSI C streams and libjf journaled text files:
UNIX text files, with records delimited by NL ("\n") must be opened like binary files, for example: "r", "w".
DOS text files, with records delimited by CRLF ("\r\n") must be opened with a special ("DOS mode") flag, for example: "rD", "wD".
Yes, sure: I'm spending half of the time in developing case tests! Use make check command to start case test procedure.
Default path is /tmp/libjf, but you can change it setting environment var TEST_TMP_PATH before configure operation; this is an example:
> export TEST_TMP_PATH=/tmp/foo/bar > ./configure
Yes, it runs case test trying all the available configurations. These are the commands to start it:
> ./configure > cd tests > ./stress_test.sh
Stress test procedure may be very slow, especially if you set environment variable JF_JOURNAL_SYNC_TYPE to "1" and use safe synchronization. If your operating system (and kernel) supports it, you can reduce elapsed time, using a "TMPFS" filesystem. If you are riding GNU/linux 2.4+ with "TMPFS" feature active, you can create a "TMPFS" filesystem for your /tmp mount point inserting something like this in your /etc/fstab:
none /tmp tmpfs defaults 0 0"TMPFS" is available on some flavor of UNIX systems.