On Wed, 2 Feb 2022 at 17:24, Robert Elz <k...@munnari.oz.au> wrote: > > Date: Wed, 2 Feb 2022 15:26:21 +0000 > From: David Brownlee <a...@absd.org> > Message-ID: > <cagn_6pave1op_jktgjfv_-irzrp+ubic_3bjkzoa4xkw77x...@mail.gmail.com> > > | So, we just need an optional flag when mounting v7fs to truncate any > | looked up filename component to 14 characters > > That's not, or shouldn't be, necessary - that always happened, the limit was > what was stored in the directory, not on the length of the pathname components > passed to namei. > > Further, v7fs (systems of that vintage) had no concept at all of a maximum > pathname length (provided there was available ram to store the string). >
(Apologies for continuing further down this rabbit hole :) Oops, my earliest unix experience was on a BSD4.3 variant, so I was spoiled by ffs and didn't realise the (in this context) helpful v7fs behaviour with overlong filename components. As a quick test extracting rescue.tar.xz into a v7fs and chrooting into rescue/sh works, and rsyncing enough to get /bin/sh chrooting also works (extracting base.tar.xz runs into issues - PR bin/56690) Actually, there were enough other issues found in PR bin/56690 that I would have to regretfully recommend against v7fs for production NetBSD systems (ahem :) David
