Bug #2030
closed
fstatfs() fails in chroot environments
Added by ftigeot over 13 years ago.
Updated over 13 years ago.
Description
While investigation a ld-elf.so.2 error, I found out the following call returns
a non-zero value in a chroot:
fstatfs(fd, &fs)
the returned value is actually ENOENT, but the corresponding file exists
On what file system does this happen?
Regards,
Alex
On Mon, Mar 21, 2011 at 09:09:27PM +0000, Alex Hornung (via DragonFly issue tracker) wrote:
Alex Hornung <ahornung@gmail.com> added the comment:
On what file system does this happen?
Hammer. root / non-root does not really make any difference.
I have written a test program available here:
http://dl.zefyris.com/fstatfs.c
Cheers,
On 3/21/2011 9:49, Francois Tigeot (via DragonFly issue tracker) wrote:
New submission from Francois Tigeot<ftigeot@wolfpond.org>:
While investigation a ld-elf.so.2 error, I found out the following call returns
a non-zero value in a chroot:
fstatfs(fd,&fs)
the returned value is actually ENOENT, but the corresponding file exists
I followed the path a bit and it fails in cache_fullpath() in
sys/kern/vfs_cache.c in line #3281 in the "if (ncp == NULL)" check.
Sascha
fixed in 92734e3dc3576d68a28eb7d539dd48de730ab82d. fstat[v]fs() was using the
wrong mount pointer when calling cache_fullpath().
Also note that the test program supplied is buggy, this line is broken and
causes the fd to be assigned the value 0:
if (fd = open(FILE_PATH, O_RDONLY) -1) ... should be
if ((fd = open(FILE_PATH, O_RDONLY)) -1) ...
-Matt
Also available in: Atom
PDF