World: r3wp

I'm actually running an experiment now.  I'm going to write a file 
that will attempt to exceed those sizes.

:-) Be sure, you have enough HD space!

The file system might have max-size for files. I remember something 
about 2 or 4GB for some file systems.

FAT32 is the one with that limit.

Yep, hit it today on FAT32 - 4GB file was produced.

I'm on NTFS.  I'll post what I find out.

currently still writing a file which is only at 668 Megs at the moment.

Anton, you created a 4GB file using REBOL or was reading one when 
you got the error?

Sorry, not using Rebol, but in Linux, creating a file in a FAT32 
partition.

ahhh ok.

I was curious because I'm interested in what happens when I hit 2099999999 
size.

Actually a bit larger than that.

I don't know where you got that number from; If I remember correctly 
the first time you can get a problem with rebol file size is at 2 
^ 31 - 1

Oh it was a generic range number based on a algorithm I was running. 
 I expect the number to be the 32 bit signed number that John posted.

Maybe it was 2 ^ 31 - your buffer size ?

That number I posted is the highest in my algorithm I could hit.

Ok, that makes sense.

p: open/direct/write/new %/k/test.bin

b: make binary! 1000000 insert/dup b #{00} 1000000 i: 0 while [not 
error? try [insert tail p b]][i: i + 1]

created file ower 5GB here... than I stoped it.

what OS?

WIN/ ntfs

ok cool.

I want to be able to do some probes on the file once I get it to 
size.

on the port rather.

The problem is with reading anyway

You having problem reading that file now?

But not impossible I guess. Using such a big files is not practical 
imho.

I think it's when you want to seek to a position greater than 2 ^ 
31 - 1

you run into a problem then.

I'm not going to read such a file if I have only 1GB memory:)

Well I'm testing a new indexing system for TRETBASE and need to know 
some significant data to fine tune it.

That is where my interest lies Anton.

Interesting the limit for file size in REBOL is 2 ** 31

when the port/state/tail value reaches 2 ** 31 it converts it to 
a negative number and gives an error which is an "access error writing 
to port".

Now the port can still be read via open/direct but no longer accessible 
via open/seek at that point.

Not sure how OLDES was able to get his file over 5GB on NTFS as my 
test was also on NTFS.

I wonder if WRITE/APPEND allows files over 4 GB?

I would have thought that write would be using open also.

REBOL should be able to break this limitation.  Even if it means 
holding a pointer to a file position and then looping over again.

I tried Oldes method and able to get it over the limit.

I noticed using his refinements I no longer have access to tail from 
querying the port.

The only limitation I could find is in /seek.

So next question - do we have any source of /seek to understand why 
we have such a limitation?

The source of OPEN, isn't. It seems likely that the 32-bit integers 
of R2 are at fault here.

Well I would assume that the 32 bit integers are being used on open/direct 
so I'm not sure why this limitation only affect /seek and not /direct 
as well.

My need is to be able to get the tail or index of files larger than 
the 32 bit integer limit.

I expect that /direct is just using file handles and isn't setting 
offsets like /seek.

I don't know what the port flags or the port/state/misc counters 
are used for.

Do you know anyway around this limit?

A work around?