!C99Shell v. 1.0 pre-release build #13!

Software: Apache/2.0.54 (Unix) mod_perl/1.99_09 Perl/v5.8.0 mod_ssl/2.0.54 OpenSSL/0.9.7l DAV/2 FrontPage/5.0.2.2635 PHP/4.4.0 mod_gzip/2.0.26.1a 

uname -a: Linux snow.he.net 4.4.276-v2-mono-1 #1 SMP Wed Jul 21 11:21:17 PDT 2021 i686 

uid=99(nobody) gid=98(nobody) groups=98(nobody) 

Safe-mode: OFF (not secure)

/usr/doc/db-3.3.11/api_c/   drwxr-xr-x
Free 318.38 GB of 458.09 GB (69.5%)
Home    Back    Forward    UPDIR    Refresh    Search    Buffer    Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    


Viewing file:     db_set_re_source.html (7.99 KB)      -rw-r--r--
Select action/file-type:
(+) | (+) | (+) | Code (+) | Session (+) | (+) | SDB (+) | (+) | (+) | (+) | (+) | (+) |
Berkeley DB: DB->set_re_source

DB->set_re_source

APIRef

#include <db.h>

int DB->set_re_source(DB *db, char *re_source);

Description

Set the underlying source file for the Recno access method. The purpose of the re_source value is to provide fast access and modification to databases that are normally stored as flat text files.

If the re_source field is set, it specifies an underlying flat text database file that is read to initialize a transient record number index. In the case of variable length records, the records are separated, as specified by DB->set_re_delim. For example, standard UNIX byte stream files can be interpreted as a sequence of variable length records separated by <newline> characters.

In addition, when cached data would normally be written back to the underlying database file (for example, the DB->close or DB->sync methods are called), the in-memory copy of the database will be written back to the re_source file.

By default, the backing source file is read lazily; that is, records are not read from the file until they are requested by the application. If multiple processes (not threads) are accessing a Recno database concurrently, and are either inserting or deleting records, the backing source file must be read in its entirety before more than a single process accesses the database, and only that process should specify the backing source file as part of the DB->open call. See the DB_SNAPSHOT flag for more information.

Reading and writing the backing source file specified by re_source cannot be transaction-protected because it involves filesystem operations that are not part of the Db transaction methodology. For this reason, if a temporary database is used to hold the records, it is possible to lose the contents of the re_source file, for example, if the system crashes at the right instant. If a file is used to hold the database, normal database recovery on that file can be used to prevent information loss, although it is still possible that the contents of re_source will be lost if the system crashes.

The re_source file must already exist (but may be zero-length) when DB->open is called.

It is not an error to specify a read-only re_source file when creating a database, nor is it an error to modify the resulting database. However, any attempt to write the changes to the backing source file using either the DB->sync or DB->close functions will fail, of course. Specify the DB_NOSYNC flag to the DB->close function to stop it from attempting to write the changes to the backing file; instead, they will be silently discarded.

For all of the previous reasons, the re_source field is generally used to specify databases that are read-only for Berkeley DB applications; and that are either generated on the fly by software tools or modified using a different mechanism -- for example, a text editor.

The DB->set_re_source interface may be used only to configure Berkeley DB before the DB->open interface is called.

The DB->set_re_source function returns a non-zero error value on failure and 0 on success.

Errors

The DB->set_re_source function may fail and return a non-zero error for the following conditions:

EINVAL
An invalid flag value or parameter was specified.

Called after DB->open was called.

The DB->set_re_source function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. If a catastrophic error has occurred, the DB->set_re_source function may fail and return DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail in the same way.

See Also

db_create, DB->associate, DB->close, DB->cursor, DB->del, DB->err, DB->errx DB->fd, DB->get, DB->pget, DB->get_byteswapped, DB->get_type, DB->join, DB->key_range, DB->open, DB->put, DB->remove, DB->rename, DB->set_alloc, DB->set_append_recno, DB->set_bt_compare, DB->set_bt_minkey, DB->set_bt_prefix, DB->set_cachesize, DB->set_dup_compare, DB->set_errcall, DB->set_errfile, DB->set_errpfx, DB->set_feedback, DB->set_flags, DB->set_h_ffactor, DB->set_h_hash, DB->set_h_nelem, DB->set_lorder, DB->set_pagesize, DB->set_paniccall, DB->set_q_extentsize, DB->set_re_delim, DB->set_re_len, DB->set_re_pad, DB->set_re_source, DB->stat, DB->sync, DB->truncate, DB->upgrade, and DB->verify.

APIRef

Copyright Sleepycat Software


:: Command execute ::

Enter:
 
Select:
 

:: Search ::
  - regexp 

:: Upload ::
 
[ Read-Only ]

:: Make Dir ::
 
[ Read-Only ]
:: Make File ::
 
[ Read-Only ]

:: Go Dir ::
 
:: Go File ::
 

--[ c99shell v. 1.0 pre-release build #13 powered by Captain Crunch Security Team | http://ccteam.ru | Generation time: 0.0036 ]--