Windows 2000 2 GB file limit

[Brian K. White]

Don Coleman wrote:
> Kenneth Brody wrote:
>
>> Fairlight wrote:
>> [...]
>>
>>
>>> I'm not suggesting it, I'm flat-out -saying- it.  I'm staring at a
>>> 3.5gig MPEG file which can be viewed completely--and was created
>>> here as well. It's on a system with exactly what you cite--Windows
>>> 2000 with NTFS. Windows 2000 with NTFS has -no- problems with files 
>>>  >2GB.
>>>
>>>
>> [...]
>>
>> Win9x systems (95, 98, and Me) have 2GB filesize limits.  NT-based
>> systems (NT, XP, 2000, and 2003) do not have these limits.
>>
>>
>>
> Ken:
>
> You are correct, W2K correctly display the file size while WIN98 does
> not.  However, fP5.0.13 can still not access this key even on W2K.
> Please confirm that this is a fP limitation and I am out of luckas
> Nancy has suggested.

see if there is a "dd" for windows you can download somewhere, or ftp the 
file to a unix box

determine 3 values:
Block Size
Count
Seek

add up the lengths of the key fields in your map + 20 more bytes
take this value and use it as the block size

guesstimate the nearest multiple of that block size that results in about 1 
gig and use that as the count
1000000 / bs = count.float
round count.float to the nearest interger = count

bs * (count -1) = seek
(the -1 is just to make sure we don't lose a record due to off-by-one error 
in my dd seek below, maybe you will get a duplicate record, but definitely 
not lose one this way)

run dd to chop the file in half right between records so you don't even lose 
any or corrupt any

dd if=key of=key1 bs=232 count=4310345
dd if=key of=key2 bs=232 seek=999999808

copy data data1
copy data data2
if there is realy no data segment, or figure out the block size as above but 
don't add 20 bytes,  use the exact same value for count as you used on the 
key segmen, don't risk re-determining it and having it come out different, 
determine a new bs and seek, and chop data into data1 and data2 as you did 
with the key.

copy the indexes, & rebuild the copies:
cp index.A index1.A
cp index.A index2.A
...
cp index.P index1.P
cp index.P index2.P

dxmaint filename -ra -e -m 1
dxmaint filename -ra -e -m 2

voila,
pfqual=1 holds the 1st half of the data.
pfqual=2 holds the 2nd half of the data.

use fp any of a dozen ways to recombine and/or archive the data


That's the theory anyway :)
Since I didn't just actually do all this stuff for real on a sample file, 
there might be a glitch or two, but if it were me this would be my starting 
point. Notice at no point do I mess with the original key, data, indexes, 
just read them. So if the new key1 & key2 don't come out just right the 
first time, no biggie, just tweak and redo until it comes out.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani