> 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 <e...@google.com> wrote: > On Sat, Feb 11, 2023 at 4:07 AM Rob Landley <r...@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@lists.landley.net > > http://lists.landley.net/listinfo.cgi/toybox-landley.net >
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
