Date: Sun, 22 May 2016 18:37:52 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 184340] PATH_MAX not interoperable with Linux Message-ID: <bug-184340-8-HSwVeOHQhi@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-184340-8@https.bugs.freebsd.org/bugzilla/> References: <bug-184340-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D184340 Jilles Tjoelker <jilles@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jilles@FreeBSD.org Status|In Progress |Open --- Comment #5 from Jilles Tjoelker <jilles@FreeBSD.org> --- The limit cannot be removed entirely without a severe rework because subsys= tems like ktrace and audit need a copy of the pathname that the user cannot modi= fy concurrently. The kernel rather likes allocating PATH_MAX or MAXPATHLEN sized buffers in general. This is already wasteful with PATH_MAX=3D1024 and even more so with 4096. Ideally, the majority of short pathnames would not waste so much memo= ry. For a local change I would change the one in sys/sys/syslimits.h. Then recompile everything including packages. There are a few nasty APIs like realpath() that implicitly depend on PATH_MAX. Applications that insist on it can use longer pathnames by passing only sho= rt segments to system calls and using openat(2) and other *at functions. For example, find and rm from the base system do this (provided symlinks are not being followed, the current directory can be opened for reading and the pathnames passed to the utility themselves are not too long). --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-184340-8-HSwVeOHQhi>