[Toybox] macOS realpath test failures

enh enh at google.com
Wed Jan 11 14:53:23 PST 2023


On Wed, Jan 11, 2023 at 12:06 PM Rob Landley <rob at landley.net> wrote:

> On 1/10/23 15:46, Rob Landley wrote:
> > I note I'm building mkroot images for the release so this bugfix won't
> be in
> > 0.8.9, but Android has its own sync points. :)
> >
> > On 1/9/23 18:10, enh wrote:
> >> and here's the ls -lR for it...
> >
> > This has been on my todo list because I need to make an f2fs filesystem,
> which
> > is flash based, so I need to fake up a flash device with an erase block
> size. (I
> > did that years ago and need to find my notes. Possibly easiest to do
> with qemu
> > instead of that weird annotate-a-block-device driver?)
>
> Huh, apparently not: I gave mkfs.f2fs a 128 meg zeroed image file and it
> assumed
> 512 sector size and ran with it.
>
> $ hd f2fs.img | less
> ...
> 00000880  6a 70 67 00 00 00 00 00  67 69 66 00 00 00 00 00
> |jpg.....gif.....|
> 00000890  70 6e 67 00 00 00 00 00  61 76 69 00 00 00 00 00
> |png.....avi.....|
> 000008a0  64 69 76 78 00 00 00 00  6d 70 34 00 00 00 00 00
> |divx....mp4.....|
> 000008b0  6d 70 33 00 00 00 00 00  33 67 70 00 00 00 00 00
> |mp3.....3gp.....|
> 000008c0  77 6d 76 00 00 00 00 00  77 6d 61 00 00 00 00 00
> |wmv.....wma.....|
> 000008d0  6d 70 65 67 00 00 00 00  6d 6b 76 00 00 00 00 00
> |mpeg....mkv.....|
> 000008e0  6d 6f 76 00 00 00 00 00  61 73 78 00 00 00 00 00
> |mov.....asx.....|
> 000008f0  61 73 66 00 00 00 00 00  77 6d 78 00 00 00 00 00
> |asf.....wmx.....|
> 00000900  73 76 69 00 00 00 00 00  77 76 78 00 00 00 00 00
> |svi.....wvx.....|
> 00000910  77 6d 00 00 00 00 00 00  6d 70 67 00 00 00 00 00
> |wm......mpg.....|
> 00000920  6d 70 65 00 00 00 00 00  72 6d 00 00 00 00 00 00
> |mpe.....rm......|
> 00000930  6f 67 67 00 00 00 00 00  6a 70 65 67 00 00 00 00
> |ogg.....jpeg....|
> 00000940  76 69 64 65 6f 00 00 00  61 70 6b 00 00 00 00 00
> |video...apk.....|
> 00000950  73 6f 00 00 00 00 00 00  64 62 00 00 00 00 00 00
> |so......db......|
>
> I do not understand what this thing is up to at all, but I suppose I don't
> really NEED to at the moment? (This is an empty filesystem, I was
> wondering what
> the formatter put into it and "a whole bunch of filetype extensions" was
> not on
> my bingo card.)
>
> >> FAIL: realpath -s .. eats symlink in $PWD
> >> echo -ne '' | cd dos && realpath -s ..
> >
> > The -s says "don't expand symlinks" so logically it means ".." should
> strip the
> > last entry off of $PWD instead of traversing the filesystem? (That's why
> it
> > expects that output, anyway...)
> >
> >> --- expected 2023-01-09 21:52:49.611701819 +0000
> >> +++ actual 2023-01-09 21:52:49.635701818 +0000
> >> @@ -1 +1 @@
> >> -/data/local/tmp/toybox-tests-tmp.a8tofxJqRN/realpath
> >> +/data/local/tmp/toybox-tests-tmp.a8tofxJqRN/realpath/one
> >
> > The ls contents look right. I'll see if I can set up a test environment
> later
> > today...
>
> Let's see...
>
> $ sudo mount -o loop f2fs.img sub
> $ cp -a generated/testdir/testdir/. sub/. # post-realpath test debris
> $ cd sub/dos
> $ toybox realpath -s ..
> /home/landley/toybox/toybox/sub
>
> Nope, it's not reproducing for me under debian's f2fs loopback mount
> either.
> Built with android-ndk-r25b just to be sure.
>
> Oddly enough:
>
> $ realpath -s ..
> /home/landley/toybox/toybox/sub/one
>
> This is a behavior difference between toybox and gnu. (Hence the "toyonly"
> on
> the test.) I have NO idea how your test plumbing would wind up running the
> gnu
> version while triggering "toyonly" to run it, though...
>

no, these tests are running on the device so no GNU realpath there. mksh
does have a realpath builtin, but that should be disabled, and seems to be:

vsoc_x86_64:/ # builtin realpath
/system/bin/sh: builtin: realpath: not found

nothing obviously interesting to me from running under strace either:

getcwd("/data/local/tmp/toybox-tests-tmp.MVTLWvjcs4/realpath/one/two",
4096) = 61
openat(AT_FDCWD, "/", O_RDONLY|O_PATH)  = 3
openat(3, "data", O_RDONLY|O_PATH)      = 4
close(3)                                = 0
openat(4, "local", O_RDONLY|O_PATH)     = 3
close(4)                                = 0
openat(3, "tmp", O_RDONLY|O_PATH)       = 4
close(3)                                = 0
openat(4, "toybox-tests-tmp.MVTLWvjcs4", O_RDONLY|O_PATH) = 3
close(4)                                = 0
openat(3, "realpath", O_RDONLY|O_PATH)  = 4
close(3)                                = 0
openat(4, "one", O_RDONLY|O_PATH)       = 3
close(4)                                = 0
openat(3, "two", O_RDONLY|O_PATH)       = 4
close(3)                                = 0
close(4)                                = 0
write(1, "/data/local/tmp/toybox-tests-tmp"...,
57/data/local/tmp/toybox-tests-tmp.MVTLWvjcs4/realpath/one
) = 57

but i do seem to be seeing what you describe as the GNU behavior:

vsoc_x86_64:/data/local/tmp/toybox-tests-tmp.MVTLWvjcs4/realpath # toybox
realpath -s dos/..
/data/local/tmp/toybox-tests-tmp.MVTLWvjcs4/realpath
vsoc_x86_64:/data/local/tmp/toybox-tests-tmp.MVTLWvjcs4/realpath # cd dos
vsoc_x86_64:/data/local/tmp/toybox-tests-tmp.MVTLWvjcs4/realpath/dos #
toybox realpath -s ..
/data/local/tmp/toybox-tests-tmp.MVTLWvjcs4/realpath/one
vsoc_x86_64:/data/local/tmp/toybox-tests-tmp.MVTLWvjcs4/realpath/dos #


hmm... running the host toybox (on the host!) i see a test pass, and strace
doesn't have the getcwd() my previous strace output started with ... it has
this instead:

newfstatat(3, "", {st_mode=S_IFREG|0644, st_size=6362320, ...},
AT_EMPTY_PATH) = 0

ah, which is probably because you won't typically have $PWD set on
Android...

  // If this isn't an absolute path, start with cwd or $PWD.
  if (*path != '/') {
    if ((flags & ABS_KEEP) && (str = getenv("PWD")))
      splitpath(path, splitpath(str, &todo));
    else {
      splitpath(path, splitpath(str = xgetcwd(), &todo));
      free(str);
    }
  } else splitpath(path, &todo);

mksh fakes it so `echo $PWD` works, but there's no _exported_ $PWD:

# toybox printenv | grep
#

> Rob
>
> Still Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20230111/5be1e1d3/attachment.htm>


More information about the Toybox mailing list