[Toybox] ltp test failure with toybox mv

[enh]

here's a weird one...

https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/controllers/cgroup_fj/cgroup_fj_function.sh#L131

test6 fails with toybox mv because toybox (reasonably enough) believes that
if it failed to unlink the _files_ it obviously can't unlink their parent
directory. but apparently that's not true for Linux cgroups... there the
file unlinks fail but the directory unlink succeeds:

openat(AT_FDCWD, "/dev/cgroup/ltp/ltp_1", O_RDONLY|O_CLOEXEC) = 4
...
unlinkat(4, "cgroup.procs", 0)          = -1 EPERM (Operation not permitted)
unlinkat(4, "tasks", 0)                 = -1 EPERM (Operation not permitted)
...
unlinkat(AT_FDCWD, "/dev/cgroup/ltp/ltp_1", AT_REMOVEDIR) = 0

coreutils on the other hand seems from strace to not even try to remove the
parent directory if there was an earlier failure.

it seems like toybox's decision about whether to unlink the source...

  // Did we make a thing?
  if (fdout != -1) {
    ...
    if (CFG_MV && toys.which->name[0] == 'm' && !err)
      if (unlinkat(tfd, try->name, S_ISDIR(try->st.st_mode) ? AT_REMOVEDIR
:0))
        err = "%s";

...really is what it says in the comment: did we _create_ something? not
"did we remove everything?", because why would you need to ask that? if
there's one thing we all know about rmdir(2) it's that the directory must
be empty.

expect, apparently, for cgroups, where that isn't true.

i scratched my head for a while about how to get that behavior in toybox
(assuming the resolution is to sigh, shake our fists at the clouds, and
work around this linux oddity), and it seems like we could use the fact
that error_msg() will have incremented toys.exitval, and add that to the
CFG_MV `if` above?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20210707/2023d243/attachment.htm>