Hi Philip and Happy New Year,

Philip Guenther <guenther@gmail.com> wrote:
> 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.

I'm strongly agree on removing unused broken codes.

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

I always expected that the safest way to mount an unknown USB disk would
be a simple command: mount -o ro,nodev,nosuid,noexec /dev/sdXY /mnt

And I think many would think that it should be safe.
I think it is unfair if I get unauthorized Kernel Memory read if I
forget to fsck a USB disk before mounting it!