Re: CVS commit: src/tests/fs/vfs

[David Brownlee <abs%absd.org@localhost>]

On Wed, 2 Feb 2022 at 17:24, Robert Elz <kre%munnari.oz.au@localhost> wrote:
>
>     Date:        Wed, 2 Feb 2022 15:26:21 +0000
>     From:        David Brownlee <abs%absd.org@localhost>
>     Message-ID:  <CAGN_6pavE1op_jktGjFV_-irzRp+ubiC_3BJKZoA4xKW77xGkw%mail.gmail.com@localhost>
>
>   | 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