> > Anyway, it would appear that I have exceeded these limits. What to
> > do? Break up the external file into smaller (<4GB) files? But then
> > what about the final size of the FB DB - it's still going to be >4GB?
> > Should I look at getting a new 64K-bit PC with 64k-bit WinXP? Change
> > OS'S? Anyone else have experience doing a massive import like this?

(I had already deleted the grandparent before noticing this, sorry about the reparenting.)

64-bit processors and 64-bit OS's are a separate issue from 64-bit file addressing. The issues are
*slightly* related, but that's about it.

64-bit processors extend registers to be 64-bits in length, allowing pretty much anything 64-bit to
be done in a single pass, rather than as a set of work-arounds. It also understands 64-bit memory
addresses. Even on 32-bit processors though, the 4 gig memory limit imposed by 32-bit memory
pointers is process-specific. The OS and processor cooperate to make it possible for several
processes to all see the same pointer, yet have their pointers mean different things.

64-bit OS's take advantage of this by doing more math using these new registers and ops, rather
than the convoluted way previously used. They can also use 64-bit memory addresses if they like,
though it seems that's rarely much of an advantage.

64-bit file addressing involves the host operating system providing functions for working with
files using 64 bits of position information, rather than 32 (or less.) Linux added some new 64-bit
only functions for doing file i/o, but then simply made it possible to compile programs differently
such that the definition of pos_t changes from a 32 bit number to a 64 bit number, without changing
any other code -- all the old file functions suddenly were able to do 64-bit stuff. Windows, as I
vaguely recall, added new function calls that take a second 32-bit parameter to fill the position
information out to 64 bits. Both operating systems (and others) did this several years ago.

The only overlap might appear if you consider functions like mmap(), which could map a very large
file (> 4 gigs) directly into a program's memory space that is bound by the limits of 32-bit memory
processing. It seems like the restriction would mainly be that you can't map more than 4 gigs of
the file into memory at a time.

Regardless, Firebird can't do anything about the fact that on-disk filesystems each have a defined
size for file size variables. FAT32 uses 32-bit numbers for filesize internally, and thus has no
idea what's happening if you try to write beyond that limit (and will start to overwrite the
beginning of the file?) NTFS uses larger variables. Under Linux, various filesystems have varying
file size limits.

http://www.suse.de/~aj/linux_lfs.html -- has a list of *nix filesystems and their limits under
different conditions.

You can use large-file-support on older operating systems and 32-bit processors. You just have to
pick the right combination of OS version and file system. Windows has had 64-bit file i/o since at
least Windows 2000, I'm not sure about before that. (Google turned up too many results about 64-bit
versions of Windows, which confuses the issue.)

-unordained