[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-tech
Subject:    Re: bogus UFS readdir
From:       Philip Guenther <guenther () gmail ! com>
Date:       2023-12-29 21:01:51
Message-ID: CAKKmsNjy2N__mbsekpygbSXANG5uuSZq8y16N_ocd1mtMZk5xw () mail ! gmail ! com
[Download RAW message or body]

On Fri, Dec 29, 2023 at 1:04 AM Otto Moerbeek <otto@drijf.net> wrote:

> On Fri, Dec 29, 2023 at 04:43:45AM +0000, Ali Farzanrad wrote:
>
> > Ali Farzanrad <ali_farzanrad@riseup.net> wrote:
> > > Hi and happy new year in advance,
> > >
> > > I have no idea why in some conditions d_type and d_namlen are swapped,
> > > but it should be consistent, right?
> > >
> > > Plus it should be better to check d_reclen against d_namlen too, right?
> >
> > And maybe it is better to have a check for d_namlen > 0 too
>
> These are some (remains) of code handling filesystems created on a
> different endian system. FreeBSD and (I think) NetBSD support that, we
> do not. I seen no immediate need to change this, unless we have a real
> bug. It might be instructional to compare to (older revisions of)
> FreedBSD code. Newer code has likely diverged too much.
>

Yeah, the support for such antique layout FFS images is not complete and
does not seem like something we would want to support.  Note that fsck_ffs
lacks the code to support such images and if you're mounting a filesystem
that you didn't fsck then you're treading a path of descent into madness.

IMHO, the code to support such old images could be removed; I think we've
diverged more than enough (particularly in ufs_readdir()!) to make keeping
it not particularly helpful when comparing against FreeBSD code.

Checking for d_namlen > d_reclen is fsck's job, adding it here is not
useful.


Philip Guenther
[prev in list] [next in list] [prev in thread] [next in thread]