Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 Jun 2014 21:29:18 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-bugs@FreeBSD.org
Subject:   [Bug 161481] [libc] mount(2) fails with ENAMETOOLONG with path shorter than 255 // 1023 characters
Message-ID:  <bug-161481-8-F2JgeiYyds@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-161481-8@https.bugs.freebsd.org/bugzilla/>
References:  <bug-161481-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=161481

Nick Hibma <n_hibma@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |n_hibma@FreeBSD.org

--- Comment #3 from Nick Hibma <n_hibma@FreeBSD.org> ---
In our NanoBSD builds we use nullfs to provide a dir with packages to install.
I changed the MAKEOBJDIR to include the full path to working directory to
provide a means to separate multiple images and versions of images.

nullfs couldn't handle the length of that path. I am -very- surprised that
nullfs is not able to handle MAX_PATH length paths.

Our workaround is the use the MD5 of the full path instead of the path itself:

# XXX Take the MD5 of the path as mount_nullfs (for packages) does not handle
long paths. See
# FreeBSD PR kern/161481.
p="$(echo "$PWD" | sed -Ee 's#^/((usr)?/home|Users)/##' | md5)"
NANO_OBJ=${NANO_OBJ:-"/usr/obj/nanobsd/$p"}

I do understand that this is actually a rather complex little bug, as it goes
across a number of APIs.

-- 
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-161481-8-F2JgeiYyds>