>Hi Peter,
>
>I hope you had a good sleep.

Mwaah.. many related dreams.. not many solutions this time. :)

>From the evidence it appears that FEOF is being determined based on 'current byte position' versus file 'size'. In this case the file size (VALUE) is smaller that the 'current byte position', so EOF. Wouldn't you say?

The fseek( lnHr, 0, 2) returns 0 indeed. The funny thing is that fseek(lnHr,2^31) nicely moves the byte pointer to that 2Gig position. IMO, fseek(,,2) should not return 0 on files that are over 2Gig, but it should return 2Gig or so. I am aware of the standpoint of the foxteam that there will be no support for files over 2Gig, but that's no justification for delivering functions that return false values on files over 2Gig, don't you think?!

>cheers
>
>>Hi Tore,
>>
>>It's now 3:35 and yes, I'm still at work. ;)
>>
>>Indeed, I have several problems currently, some related to files that are over 2Gig, others related to insufficient support for network mappings. For example, I just wrote the routine BetterDiskSpace(). This function also returns the amount of free bytes on a NETWORK MAPPING. The VFP diskspace() function only works fine for drive letters.
>>
>>The fopen() function reads fine as long as the 2Gig barrier is not reached. So, I think that feof() should work fine uptill that moment too, don't you think?!
>>
>>I go to bed now. |) ( the | should represent closed eyes )
>>
>>>Hi Peter,
>>>
>>>working late today? :-)
>>>
>>>Since VFP does not support any file that is over 2GB, NO info or No function or command regarding and/or affecting such files can be trusted. Period.
>>>
>>>>Hi All,
>>>>
>>>>In the case of a file that's over 2Gig FEOF() always returns True, even when FGETS() successfully returns a (first line) string. Is this a bug?