[Toybox] [PATCH] Fix SEC_TYPE for vfat and iso9660

[Eric Molitor]

 > P.P.S. What _is_ LABEL_FATBOOT anyway?

Bootable FAT has two labels, one on the boot sector and one as a ROOT
directory entry with type 'Volume Label'. LABEL_FATBOOT is the label on the
boot sector. The entry in the root directory is equivalent to a volume
label in a modern FS and MSFT and everyone treats it as such and ignores
the label on the boot sector.

http://www.c-jump.com/CIS24/Slides/FAT/FAT.html
https://lkml.org/lkml/2017/10/4/512

- Eric

On Sat, 11 Feb 2023 at 17:06, enh <enh at google.com> wrote:

> On Sat, Feb 11, 2023 at 4:07 AM Rob Landley <rob at landley.net> wrote:
> >
> >
> >
> > On 2/10/23 07:33, Eric Molitor wrote:
> > > Actually you were spot on with your feedback. I also checked with
> e2fsprogs,
> > > util-linux and busy box blkid and this is the most consistent ordering
> of output
> > > for SEC_TYPE.
> > >
> > > - Eric
> > > ---
> > >  tests/blkid.test   | 2 +-
> > >  toys/other/blkid.c | 2 +-
> > >  2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/tests/blkid.test b/tests/blkid.test
> > > index 4c385dcb..7e625492 100755
> > > --- a/tests/blkid.test
> > > +++ b/tests/blkid.test
> > > @@ -29,7 +29,7 @@ testing "f2fs" "BLKID f2fs" \
> > >    'temp.img: LABEL="myf2fs"
> UUID="b53d3619-c204-4c0b-8504-36363578491c"
> > > TYPE="f2fs"\n' \
> > >    "" ""
> > >  testing "iso" "BLKID iso" \
> > > -  'temp.img: SEC_TYPE="msdos" LABEL="MYISO"
> UUID="1970-01-02-12-55-42-00"
> > > TYPE="iso9660"\n' \
> > > +  'temp.img: LABEL="MYISO" UUID="1970-01-02-12-55-42-00"
> TYPE="iso9660"\n' \
> > >    "" ""
> >
> > My TEST_HOST on devuan is doing UUID= before LABEL= for isofs. No idea
> why?
> >
> > --- expected    2023-02-11 05:59:58.915956238 -0600
> > +++ actual      2023-02-11 05:59:58.923956238 -0600
> > @@ -1 +1 @@
> > -temp.img: LABEL="CDROM" UUID="2023-02-08-04-47-27-00" TYPE="iso9660"
> > +temp.img: UUID="2023-02-08-04-47-27-00" LABEL="CDROM" TYPE="iso9660"
> >
> > Let's see what gentoo is doing... doesn't make it that far because it
> says
> > BLOCK_SIZE=1024 for ext2. Of course. (util-linux 2.33 vs 2.38.)
> >
> > Right VERBOSE=all and... well, the weird "cdrom reports fields in
> reverse order
> > except TYPE= is still at the end" remains true, but the new util-linux
> version
> > added BLOCK_SIZE to most things, and a redundant looking LABEL_FATBOOT
> to msdos
> > and vfat.
> >
> > I'm going to check in a wild guess at "currently least wrong", and throw
> the iso
> > image I made on ancient knoppix into the test file dir so it has
> something to
> > pass against for the moment so I can push stuff without obviously
> breaking make
> > tests.
> >
> > And then go BACK to trying to finish the shell read builtin instead of
> diverging
> > into adding BLOCK_SIZE just now. (NO idea how to genericize that across
> > different filesystems, unless maybe they're consistent about storing it
> as a
> > 1<<SIZE value?)
> >
> > Rob
> >
> > P.S. Would running the output through:
> >
> >   sed 's/" \([A-Z]\)/"\n\1/g' | sort | xargs
> >
> > be cheating? Mine producing fields in a consistent order and util-linux
> NOT
> > doing so is a divergence, but I don't think it's necessarily a _bug_?
>
> iirc that was my suggestion last time this came up... afaict, upstream
> doesn't really care about ordering (because they're assuming these are
> being interpreted as assignments by something that itself doesn't
> care), and it does just change over time.
>
> > P.P.S. What _is_ LABEL_FATBOOT anyway?
> > _______________________________________________
> > Toybox mailing list
> > Toybox at lists.landley.net
> > http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20230212/9c245e02/attachment.htm>