fstatfs() fails in chroot environments
While investigation a ld-elf.so.2 error, I found out the following call returns
a non-zero value in a chroot:
the returned value is actually ENOENT, but the corresponding file exists
#2 Updated by ftigeot almost 4 years ago
On Mon, Mar 21, 2011 at 09:09:27PM +0000, Alex Hornung (via DragonFly issue tracker) wrote:
> Alex Hornung <firstname.lastname@example.org> 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:
#3 Updated by swildner over 3 years ago
On 3/21/2011 9:49, Francois Tigeot (via DragonFly issue tracker) wrote:
> New submission from Francois Tigeot<email@example.com>:
> While investigation a ld-elf.so.2 error, I found out the following call returns
> a non-zero value in a chroot:
> 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.
#4 Updated by dillon over 3 years ago
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) ...