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>