autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Large File Support


From: Guido Draheim
Subject: Re: Large File Support
Date: Mon, 10 Nov 2003 22:32:52 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313



Bob Friesenhahn wrote:
On Mon, 10 Nov 2003, Guido Draheim wrote:

That may be difficult to accomplish.  I am not aware that Windows
stdio and other high-level "Windows" I/O interfaces support large
files since the APIs are 32 bit.  You need to use _read, _write,
_lseeki64, & _telli64 to support large files under Windows.

stdio does not care about off_t anyway, and that's what fseeko
is for (AC_FUNC_FSEEKO). - And actually, the newer nt kernel is
completely 64bit largefile inside and exports all the necessary
API calls to let user applications work with largefiles. It's
just not as easy as with the the posix "magic" define that we come
to use through AC_SYS_LARGEFILE - you have to invent your own
mappings to the win32 lfs transitional api which happens to be
named slightly different than the posix lfs transitional api.
see http://ac-archive.sf.net/largefile/win32.html for reference.


The stdio implementation and interface certainly depends on file
offsets.  My point is that stdio does not support 64-bit offsets under
x86 Windows. This is in spite of NT and NTFS being able to support
64-bit offsets.  The link you referenced seems to say the same thing
as I did.

Bob
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen


Interesting hint, and there's more to it. Any application using the
libc stdio api can not tell exactly whether it uses the 64bit largefile
kernel api or not. It's generally unsafe to pick up a fileno() and
chew on it with largefile calls - even that it is possible, the LFS
summit pages have a few pages reserved for discussion on that but to
me it sounds like they are unsure what effects might results. Same
for the inverse of wrapping a largefile file-id via fdopen(). It's
best to not mix it up.

For the unix systems however we may safely expect that unix vendor
will ship along a libc implementation that takes advantage of 64bit
fileoffsets of its kernel, so the fileno is really a largefile one.
That lowers the number of problems in crossing over the api sides.
   http://www.opengroup.org/onlinepubs/007904975/functions/ftell.html
describes how unix stdio implementations are asked to check the
kernel fileoffset return value and make that an EOVERFLOW if the
stdio return value would not be able to represent the real value.

With win32 systems that might be slightly different however since
here the libc is not system-specific but compiler-specific. Each
compiler vendor and compiler version may link its programs with
a different libc implementation and it is uncertain whether that
libc implementation takes advantage of kernel largefile calls.
Actually, I just do not know but I expect that the most simple
path has been used and the win32 stdio api is fully limited to
32bit  on 32bit cpus, but that nay FUD and we better ask a guru.

cheers,
-- guido                                  http://google.de/search?q=guidod
GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- (geekcode)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]