[erlang-questions] efile_drv.c bug?

[Martin Dvořák]

Hello,

I think any modern OS wouldn't dare use 32 bit integers to represent 
file offsets, sign or no sign. For example ext3 is capable of holding a 
2TB file so I'd expect the OS to be able to address any byte of it. I 
store ~500GB disk images on ext3 without problems (on a 32 bit 
architecture).

However, FAT32 has a 4GB file size limit which may be the problem here. 
The solution may be NTFS which has 2^64 bytes limit.

/Martin

Lev Walkin wrote:
> Jachym Holecek wrote:
>> On Tue, 17 Jun 2008 12:16:52 +0200, Raimo Niskanen  
>> <raimo+erlang-questions@REDACTED> wrote:
>>> On Mon, Jun 16, 2008 at 01:10:15PM -0700, Darren New wrote:
>>>> Any idea why Windows (XP/SP2/32bit) can't handle files >4G but Linux can
>>>> with the same release? Is this something expected to get fixed  
>>>> eventually?
>>> If I recall correctly, file pointers (off_t) are signed in Windows
>>> but there are extensions in Unix that use unsigned off_t but
>>> ((off_t) -1) as an error return value, so it is possible on
>>> many 32 bit Unixes to have almost 4GByte files, but 32 bit
>>> Windows is stuck with its 2GByte limit.
>>>
>>> Someone correct me!?
>> Upon quick inspection off_t seems to be int64_t on NetBSD and
>> 'long int' on Linux. So it's signed on at least two Unices.
> 
> 
> Single Unix Specification version 3, IEEE Std 1003.1
> specifies
> 
> 	blkcnt_t and off_t shall be signed integer types.
> 
> http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/types.h.html