[Toybox] macOS realpath test failures

Rob Landley rob at landley.net
Sat Dec 3 01:16:31 PST 2022



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.

> +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?

Rob


More information about the Toybox mailing list