[erlang-questions] : file:read_file/2 bug?

Raimo Niskanen <>
Mon May 5 15:31:37 CEST 2008

On Thu, May 01, 2008 at 03:27:55PM +0200, Christian S wrote:
> On Thu, May 1, 2008 at 4:36 AM, Serge Aleynikov <> wrote:
> > For some reason file:read_file/1 always returns empty binary when
> >  reading from any file in the "/proc" filesystem.
> Running strace reveals what is done behind the scenes:
> stat64("/proc/self/environ", {st_mode=S_IFREG|0400, st_size=0, ...}) = 0
> open("/proc/self/environ", O_RDONLY|O_LARGEFILE) = 7
> close(7)                                = 0
> Looking at /erts/emulator/drivers/unix/unix_efile.c one can also see
> that efile_openfile calls stat() on the filename before it open() the
> file.
> I dont understand why everything is done in efile_openfile that is
> done, but my guess is that if one first open() the file then use
> fstat() on the file descriptor, then the proc filesystem would report
> nonzero file length.

efile_openfile begins with a stat() to check that the file is
a regular file. After open() it returns the size to the caller
of efile_openfile, that is efile_drv.c, so it can know how large
buffer to allocate for the file contents.

To begin with a stat() then open() and then do a stat()
for the size on the file descriptor might be a fix to use
on the "/proc" file system. E.g "/dev/null" has already got
special treatement, so why not "/proc".

> Understanding would make it worthwile to submit a patch for the efile driver.
> The linux kernel generates the proc file's content as a snapshot at
> the instance the file is opened. Before open() it doesnt know how long
> the content will be.
> _______________________________________________
> erlang-questions mailing list
> http://www.erlang.org/mailman/listinfo/erlang-questions


/ Raimo Niskanen, Erlang/OTP, Ericsson AB

More information about the erlang-questions mailing list