[buildd-tools-devel] Bug#566513: kfreebsd: file name too long problem?

[Jens Thiele]

Aurelien Jarno <aurelien at aurel32.net> writes:

> Actually it doesn't, it's just that the chroot's name I used was a bit
> smaller. 

ok

> If we find from where this limit come, we can probably increase
> it (most probably in the kernel).

Looking at the reported limits:

cat test.c && make -k test && ./test
#include <stdio.h>
#include <limits.h>
#include <unistd.h>
#include <dirent.h>

#define x(x) do{printf("%s=%d\n",#x,x);}while(0)
#define p(x) do{printf("%s=%d\n",#x,pathconf("/",x));}while(0)

int main()
{
  x(PATH_MAX);
  x(_POSIX_PATH_MAX);
  x(NAME_MAX);
  x(MAXNAMLEN);
  x(FILENAME_MAX);
  x(_POSIX_NAME_MAX);
  p(_PC_NAME_MAX);
  p(_PC_PATH_MAX);
  return 0;
}
make: »test« ist bereits aktualisiert.
PATH_MAX=1024
_POSIX_PATH_MAX=256
NAME_MAX=255
MAXNAMLEN=255
FILENAME_MAX=1024
_POSIX_NAME_MAX=14
_PC_NAME_MAX=255
_PC_PATH_MAX=1024

So depending on the interpretation of those values (i only did a quick
look) this is a kernel or libc bug right?

I guess it is a kernel bug. A quick look at the source did not reveal
something obvious in the nullfs code. A really wild guess in a
completely different corner (i am really a noob regarding (k)freebsd):

io:/usr/src# grep 80 -r .|grep define|grep -i MAX|grep procfs
./kfreebsd-source-8.0/sys/sys/procfs.h:#define PRARGSZ          80
/* Maximum argument bytes saved */

oha this works:
$cat /proc/mounts > /etc/mtab.tmp
$umount /proc
$mv /etc/mtab /etc/mtab.old
$grep -v procfs /etc/mtab.tmp > /etc/mtab
$mkdir \
/var/lib/schroot/mount/stable-kfreebsd-amd64-7eb0b99b-7aef-492e-85c7-fa51bc948bd
$mount -t nullfs /usr/local/sbuild_squeeze \
/var/lib/schroot/mount/stable-kfreebsd-amd64-7eb0b99b-7aef-492e-85c7-fa51bc948bd8
$ls \
/var/lib/schroot/mount/stable-kfreebsd-amd64-7eb0b99b-7aef-492e-85c7-fa51bc948bd8
bin  boot  build  dev  etc  home  lib  lib64  media  mnt  opt  proc
root  sbin  srv  sys  tmp  usr  var
$umount \
/var/lib/schroot/mount/stable-kfreebsd-amd64-7eb0b99b-7aef-492e-85c7-fa51bc948bd

Looks like a procfs bug? Can you take over this one? I really don't have
a clue - and I don't have the time to dig into this at the moment.

Greetings
Jens