[Bug 184340] PATH_MAX not interoperable with Linux

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184340

--- Comment #6 from Niall Douglas <s_bugzilla at 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.