https://github.com/rupurt/vbisam
Git mirror of the VBISAM CVS repository
https://github.com/rupurt/vbisam
Last synced: 11 months ago
JSON representation
Git mirror of the VBISAM CVS repository
- Host: GitHub
- URL: https://github.com/rupurt/vbisam
- Owner: rupurt
- License: lgpl-2.1
- Created: 2025-02-14T23:50:21.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2025-02-15T00:02:12.000Z (over 1 year ago)
- Last Synced: 2025-07-11T06:06:52.538Z (12 months ago)
- Language: C
- Homepage: https://sourceforge.net/p/vbisam/code/
- Size: 298 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.64bit
- Changelog: CHANGELOG
- License: COPYING.LIB
Awesome Lists containing this project
README
A quick note for whomever tries using VBISAM in 64-bit mode...
--------------------------------------------------------------------------------
When using the 64-bit version of VBISAM, the operating system *MUST* fully
support all the various 64-bit modes of system calls. Additionally, the
filesystem upon which the 64-bit files resides must *ALSO* support 64-bit
files. For example, one of my Linux machines has a 2.2.19 kernel, glibc2.2.3,
ext2 filesystems. Any attempt to make it lock past 0x7fffffff will fail with
an EOVERFLOW error. Looking at the underlying system code (fs/locks.c) it
surely appears that it's 64-bit compliant. Therefore, I can only assume that
the issue is in the GLIBC 2.2.3 code itself. However, I also tried to *BYPASS*
the glibc code that was returning EOVERFLOW by making a low-level system call
(using syscall) and only managed to change the problem from EOVERFLOW to
EINVAL. (I must be doing SOMETHING wrong huh?)
Specifically, this means the following list of system calls:
open() Although no arguments to this call are 64-bit in nature,
*some* operating systems demand that any file that needs to
be accessed in 64-bit mode must use open64() instead of open().
This change can be effected simply in the vbLowLevel.c module
lseek() Similar rules as per open() above. Note that some systems
require you to use lseek64(), others require you to use llseek()
and *GOOD* systems allow you to use lseek() by making it a macro
for lseek64().
This change can be effected simply in the vbLowLevel.c module
Additionally, VBISAM makes extensive use of the off_t typedef.
If off_t is not a 64-bit quantity when VBISAM is compiled in
64-bit mode, you may need to defined a simple macro in the
isinternal.h include file to map off_t to loff_t, off64_t or
whatever *YOUR* system needs!
read() The read and write system calls should both return an ssize_t
write() and have a size_t passed as the third argument. VBISAM never
requires size_t or ssize_t to exceed 10-bits for the data /
index files and 16 bits for the log file. Nevertheless, these
system calls need to be able to perform their functions when
the offset into the file exceeds 32-bits.
fcntl() This one is usually the FIRST problem you'll encounter. VBISAM
expects both the l_start and l_len parameters in the flock
structure passed to fcntl when the F_SETLK or F_SETLKW commands
are used to be 64-bit quantities. You *might* need to play
around with flock versus flock64 etc in vbLowLevel.c to get this
to work.