[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Filesystems >= 4GB
From:       Derek Fountain <fountai () hursley ! ibm ! com>
Date:       2000-11-09 13:03:53
[Download RAW message or body]

> Under Linux it uses a 32 bit int for off_t, so you're probably right for
> Linux. I'm not sure what would happen if you did lseek(fd, bigoffset,
> SEEK_CUR) several times, though. That'd make the return value wrong, at
> least, though. Linux seems to have functions like 'open64' declared in
> headers (but I can't find man pages). The 'open' man page on Redhat 6.1
> suggests it just plain can't do it.

If you compile with "-D_LARGEFILE64_SOURCE" you get the 64
bit access functions from glibc made available. These are 64
bit versions of the standard functions named, eg., open64,
lseek64, and so on. off64_t is the correct type to use with
these.

If you compile with "-D_FILE_OFFSET_BITS=64" the 64 bit
versions of the standard functions are used in place of the
normal ones automatically: open() in your code is switched
by the preprocessor to open64(), etc. This trick rarely
works with complex programs - one use of 'int' instead of
'off_t' anyware in the code, for example, will cause it to
break. A proper porting effort to the *64 functions is
almost always required.

Linux itself is 64 bit clean as of 2.4test-*. 2.2.x kernels
have a 64 bit clean ext2fs, but the VM subsystem is limited
to 32 bit extents. You should also ensure you are running a
glibc-2.1.3 (I think) since large file support was buggy
before that.
 
>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]