Erts doesn't support 64 bit files?

[Mikael Pettersson]

On Sat, 6 Jul 2002 01:30:07 -0400, Shawn Pearce wrote:
>So apparently OTP R8B-1 doesn't support 64 bit files...
>
>	$ erl
>	Erlang (BEAM) emulator version 5.1.1 [source] [hipe] [threads:0]
>
>	Eshell V5.1.1  (abort with ^G)
>	1> {ok, F} = file:open("test2.dat", [raw, binary, write]).
>	{ok,{file_descriptor,prim_file,{#Port<0.26>,5}}}
>	2> file:position(F, (1 bsl 31)-1).
>	{ok,2147483647}
>	3> file:write(F, "ab").
>	File size limit exceeded
>	$
>
>Causes the entire system to crash.  This is on x86 Debian Potato,
>using the 2.4.18 kernel.  It appears as though the crash
>may actually be caused by the 32 bit write system call being
>used by the efile driver, and not by erts.  Kind of hard to
>guard against a crash caused by the C library.  :-(
>...
>In the mean time, I'm may write a new device driver that can
>handle the 64 bit files on XFS, as well as to support XFS's Direct IO,
>to bypass the kernel buffer cache.  Or just write a poor man's version
>which splices the data across multiple 2GB files, and debug carefully.

The bug is in erts. If you don't open(2) a file with O_LARGEFILE in
the flags, the kernel sends SIGXFSZ to you if your write(*) would cause
the file size to exceed $2^{31}-1$ bytes. This shows up as a core dump
in glibc's write() procedure, but that's not glibc's fault.

The application should #define _LARGEFILE64_SOURCE before its #includes,
as an indication of it being ready to handle 64-bit off64_t etc.

(*) I haven't checked but a write to an mmap():ed page could also grow
a file and might have similar behaviour as write().

/Mikael