Under some circumstances, the symbolic link /proc/<anything>/file points to "unknown". In my experiments it seems that this is the case if a directory is created and/or removed in the as the executable and the executable is called with a relative path. Some of the sysctl variables vfs.cache.numfullpathfail[1-4] are increased. This problem causes one test failure in perl5.7.3. Fix: ??? How-To-Repeat: Compile the program below: ---------------------------------------------------------------------- #include <unistd.h> main() { char buf[1024]; int len = readlink("/proc/curproc/file", buf, 1024); if (!len) exit(1); buf[len]=0; printf("<%s>\n", buf); } ---------------------------------------------------------------------- If run as ./a.out, it works OK. However, if a subdirectory in the same directory is deleted, then the program returns "unknown": mkdir foo ; rmdir foo ; ./a.out This works again: mkdir foo ; rmdir foo ; `pwd`/a.out
On Sat, Mar 09, 2002 at 12:28:07PM +0100, Slaven Rezic wrote: > If run as ./a.out, it works OK. > However, if a subdirectory in the same directory is deleted, > then the program returns "unknown": > > mkdir foo ; rmdir foo ; ./a.out > > This works again: > > mkdir foo ; rmdir foo ; `pwd`/a.out This is the same problem which sometimes caused the Linux emulators getcwd to fail. The linux emulation code has since been fixed to try harder, as Linux applications expect it to. I'm not sure that people would be in favour of making procfs try harder, as procfs doesn't even have to be mounted for most things in FreeBSD now. If you did want to try and fix it, then the place to start looking would be at the Linux emulation getcwd code in /usr/src/sys/compat/linux/linux_getcwd.c. David.
State Changed From-To: open->closed A bug in a subsystem that is deprecated.