[Toybox] macOS realpath test failures

Sat Dec 3 08:50:55 PST 2022

On Sat, Dec 3, 2022 at 1:05 AM Rob Landley <rob at landley.net> wrote:

>
>
> On 12/2/22 12:19, enh wrote:
> >
> >
> > On Wed, Nov 30, 2022 at 1:54 PM Rob Landley <rob at landley.net
> > <mailto:rob at landley.net>> wrote:
> >
> >     On 11/28/22 12:41, enh via Toybox wrote:
> >     > github CI caught a few failures
> >
> >     Sigh. There's a reason this has been on the todo list for literally
> years. It's
> >     corner cases all the way down and I don't have a mac test
> environment. (Works on
> >     linux not on mac means a libc function is returning something
> different,
> >     possibly because a syscall did, possibly because the VFS did
> something funky...)
> >
> >     > (
> https://github.com/landley/toybox/actions/runs/3561813808/jobs/5983047254
> >     <
> https://github.com/landley/toybox/actions/runs/3561813808/jobs/5983047254
> >):
> >     >
> >     > PASS: realpath -s
> >     >
> ............................................................................
> >     > ................................................
> >     > realpath: dos/three: Not a directory
> >
> >     Not a directory? Up top we did:
> >
> >       mkdir -p one/two/three
> >       ln -s ./one uno
> >       ln -s one/two dos
> >
> >     I don't THINK anything's done a cd or filesystem write since then?
> >     (one/two/three is a directory and dos points to "one/two"...)
> >
> >
> > *~/toybox/generated/testdir/testdir$ *ls -Rl
> >
> > total 8
> >
> > -rw-r--r--  1 enh  primarygroup   0 Dec  2 10:04 actual
> >
> > lrwxr-xr-x  1 enh  primarygroup   7 Dec  2 10:04 dos -> one/two
> >
> > -rw-r--r--  1 enh  primarygroup  54 Dec  2 10:04 expected
> >
> > -rw-r--r--  1 enh  primarygroup   0 Dec  2 10:04 file
> >
> > drwxr-xr-x  3 enh  primarygroup  96 Dec  2 10:04 one
> >
> > lrwxr-xr-x  1 enh  primarygroup   5 Dec  2 10:04 uno -> ./one
> >
> >
> > ./one:
> >
> > total 0
> >
> > drwxr-xr-x  3 enh  primarygroup  96 Dec  2 10:04 two
> >
> >
> > ./one/two:
> >
> > total 0
> >
> > drwxr-xr-x  2 enh  primarygroup  64 Dec  2 10:04 three
> >
> >
> > ./one/two/three:
> >
> > total 0
> >
> > *~/toybox/generated/testdir/testdir$ *
> >
> > i added a bit of printf debugging to see exactly where it's failing, and
> it's
> > the openat() in the loop at the bottom of xabspath():
> >
> > PASS: realpath -s
> > openat(4, three) 2 error
> > realpath: dos/three from /Users/enh/toybox/generated/testdir/testdir:
> Not a
> > directory
>
> Let's see what freebsd does... Sigh, freebsd 11 is apparently a bit stale.
>
> Did you know that if you wget
>
> https://download.freebsd.org/ftp/releases/VM-IMAGES/13.0-RELEASE/amd64/Latest/FreeBSD-13.0-RELEASE-amd64.raw.xz
> and unxz it and do "kvm FreeBSD-13*.raw -m 4096" and log in as root and
> "pkg
> install gmake" and gsed and bash and git (over 20 packages?!?) and then
> "adduser
> landley" and answer far too many questions (just DO it will you?) and then
> "su -
> landley" and git clone https://github.com/landley/toybox it says the
> filesystem
> is out of space?
>
> The filesystem resizing dance (more or less from
> https://people.freebsd.org/~rodrigc/doc/handbook/disks-growing.html) is:
>
>   kill kvm ("shutdown -h now" if you like but halt didn't exit.)
>   truncate -s 8G Freebsd-13*.raw
>   kvm -drive format=raw,file=freebsd-13.raw -m 4096
>   # because the qemu loons decided to punish normal -hda for NO REASON
>   gpart recover ada0
>   gpart show ada0 # add last two sizes...
>   gpart resize -i 4 -a 4k -s 14613342 ada0
>   sysctl kern.geom.debugflags=16
>   growfs /
>
> (Yes the web page says growfs /dev/ada0p4 but that doesn't work, you have
> to
> give it the mounted directory. And I could ignore the swap partition
> fiddling
> because 13 has it before the filesystem rather than after.)
>
> Anyway, THEN I could git clone the thing, and go:
>
>   cd toybox
>   gmake clean bsd_defconfig toybox
>
> At which point it dies trying to build openvt and not finding linux/vt.h
> so I
> remove CONFIG_CHVT=y from kconfig/freebsd_miniconfig and try again, and
> now the
> linker failed with undefined symbol get_block_device_size because
> lib/portability.c has #if defined(__APPLE__) elif defined(__linux__) #elif
> defined(__OpenBSD__) and I need to step away from the keyboard for a bit.
>

yeah, if they'd spent less time fighting each other, they might have had
more direct impact (rather than indirect through having bits reused in
Android/macOS/Windows)!

i think the ifdefs are mostly my fault, because i was only thinking in
terms of __APPLE__ and __linux__, and since __linux__ was the default for
toybox _without_ portability.c, i was using #if defined(__APPLE__) as a
"here's the weird special case".

but if we're expecting to support macOS/iOS _and_ the three main BSDs (and
we haven't even heard from the really niche ones yet, which have their
_own_ #defines!), maybe

#if defined(__linux__)
#else // Some kind of BSD
#endif

should be the default idiom? and we can just add #elif as/when needed for
genuine special cases?

> > +realpath 35535  enh    4r  LINK               1,18        7
>  19337567
> > /Users/enh/toybox/generated/testdir/testdir/dos
> > make: *** [test_realpath] Error 1
> > ~/toybox$
> >
> > (the lsof output there shows you what dirfd=4 is actually pointing to.)
>
> MacOS opened the symlink. And then refuses to use that as an openat() base
> because the symlink points to a directory but is not itself a directory.
> Great.
>
> Note I did _NOT_ give it O_NOFOLLOW. In fact the Linux man 2 openat says
> that
> O_NOFOLLOW is a FreeBSD extension. I wonder if FreeBSD gets it right?
>

yeah, hard to know without trying it. i've no idea how much apple's BSD
"personality" grafted on to the mach stuff actually shares code with BSD.
(or whether it _did_ once but effectively forked in the 1980s in the NeXT
days, and has gone its own path since then.)

> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20221203/29d9ab5c/attachment-0001.htm>