Date: Sun, 22 May 2016 22:03:04 +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-VU583T0YxH@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=184340 --- Comment #6 from Niall Douglas <s_bugzilla@nedprod.com> --- (In reply to Jilles Tjoelker from comment #5) I appreciate the detail in your reply. However, this is not a code development problem - as you mention, openat() is the correct solution to programming long paths. Rather it's a user problem - we are stuck with software written by others which was designed around a Linux PATH_MAX of 4096. Being that we cannot rewrite all this software to not be so stupid, it generates substantial gotchas for end users. In terms of how to refactor the BSD kernel to handle this, I believe NT simply uses dynamic memory allocation for all paths, and therefore the 64Kb path limit is tractable except when frequently modifying paths as the win32 layer likes to do. An ideal solution for BSD would be some sort of variant storage which could be either 256 bytes of path or a dynamic memory allocation to a path. Perhaps a zero length path could mean "pointer to a dynamically allocated path follows", so something like: union { char path[256]; // for paths < 255 struct { char _zero; // lowest byte in memory is zero char _magic; // magic marker byte to detect unioned path unsigned short length; // length of path char *path; // dynamically allocated pointer to path }; }; Anyway, I'm no expert in the BSD kernel, but I would find it nice to not have to install ZFS on Linux just so I can zfs snapshot the volume onto FreeBSD as my sole method of working around the BSD PATH_MAX limit. -- 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-VU583T0YxH>