| Age | Commit message (Collapse) | Author |
|---|
|
Posix says you removing a non-empty directory "shall fail" in both:
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/unlinkat.html
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/rmdir.html
So toybox mv went ahead and unlinked the directory even if the contents
hadn't all been deleted because posix guarantees it to be harmless. But
cgroups (https://lwn.net/Articles/679786/) deletes the non-empty directory,
thus the Linux Test Project's cgroups_fj_function test6 was failing with
toybox mv because they depend on not triggering the posix violating behavior.
Work around it by having mv DIRTREE_SAVE failing nodes and then check for
a non-empty ->child in the COMEAGAIN as a signal not to unlink the dir.
While I'm there do some code cleanup, add a cp -i test...
|
|
|
|
new lib/ flag), allow -s to be fraction of a second, inline (anonymous)
struct so globals.h isn't using an incomplete type, blank line in
GLOBALS() between option args and other variables, collate
tail_continue() to one function, add test.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When using -t to inspect an archive, cpio would try to set the owner of
any symlink in the archive, even though the symlink wasn't created by
the command previously.
This would lead to two results, either the command fails with a "No such
file or directory" message when trying to lchown() the symlink path, or
an existing file, with the name of the symlink, is lchown()-ed.
Guard the lchown() function call with a "if (!FLAG(t))" block, and add
regression test for this.
|
|
legacy cpio think it's reading from 1970's era reel-to-reel magnetic tape.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Not fully wired up yet, probably a bunch of regressions.
|
|
|
|
I broke this when I added the masking out of the S_IFMT bits for macOS,
because string_to_mode needs the full mode with those extra bits,
specifically so that it can recognize directories for +X to work.
I've duplicated chtest rather than change chtest to explicitly set the
modes to 000 before running the given chmod command because I didn't
want to touch *all* the tests and obscure the addition of just one.
|
|
A tar file created by toybox tar with values large enough to need
base-256 rather than ASCII octal caused a tar reader to crash, and
caused GNU tar to complain.
I note from the docs at
https://github.com/libarchive/libarchive/blob/master/libarchive/tar.5#L326
that they imply that only the top *bit* should be set to indicate this
format, not the whole top byte, to give a 95-bit or 63-bit field. But I
don't think we can hit that in practice?
Bug: http://issuetracker.google.com/181683612
|
|
|
|
|
|
|
|
And fix one test for NUL that should be a length test for -z support
|
|
|
|
Use "" instead of '' to quote command as the command contains expandable
variables.
Change-Id: Iaa8825e56243b369199588cbf6e47a1aba985804
|
|
|
|
by not writing as much payload as the header promised.
|
|
Add a test, with comment that "make install_test" doesn't currently exist...
|
|
Starting two netcats at the same time and expecting them to be able to
talk to each is a little optimistic. I don't know whether `sleep .1`
will be sufficient, but wanted to try that before going to `sleep 1`
since neither the toybox nor the github nor the Android infrastructure
is running these tests in parallel, those seconds add up.
Right now this has a ~20% flake rate on the Android infrastructure. I
was able to reproduce the flake locally with `while true ; do make
test_netcat ; done` on my desktop before this patch, but not after.
(Though my desktop is way overpowered for just running that, whereas the
build servers tend to be pretty busy, which is why I reserve the right
to return later with a longer delay.)
|
|
|
|
|
|
and address TODO where -z was still splitting patterns on \n
|
|
|
|
mksh doesn't support the {a..b} bashism or the ${!name} bashism, causing
the tests to fail on Android.
This works for me on both mksh and bash (both tested on Debian).
|
|
Add new toy `base32`. Add tests for `base32`.
base32 is added by adapting the base64 encode/decode function to also do
base32 encoding/decoding. Then their respective main functions set up
the global parameter `n` to be the number of bits used in the encoding
(5 for base32 and 6 for base64) and `align` to align the result to a
certain length via padding. These are deliberately kept as parameters to
enable future expansion for other bases easily.
|
|
|
|
|
|
|
|
couldn't handle chmod +s in /tmp. Try to make test_chmod clear out debris
and teach make clean to chmod -R generated before deleting it.
|
|
|
|
|
|
The GNU tar manual, when talking about the `tar --transform` option that I
need to implement, describes the 'x' flag by saying "regexp is an extended
regular expression (see section 'Extended regular expressions' in GNU sed)".
Only it turns out that even the latest GNU sed doesn't actually have
that flag. It's unique to `tar --transform`. That link is just telling
you that the sed manual will explain extended regular expressions, not
that GNU sed also supports the 'x' flag.
So I don't know whether we want this in toybox sed after all. (It made
sense that sed would have such a flag, but no sed that I know of
actually does.)
|
|
Based loosely on the Plan9/Inferno utility, and a convenient way to go back
and forth between code points and utf8 sequences.
This patch also fixes a couple of bugs in wctoutf8 (and the tests for this
toy effectively serve as unit tests for wctoutf8/utf8towc).
|
|
The rest of `make tests` all pass on a Raspberry Pi 400.
|
|
|
|
The AOSP build doesn't use tr (or anything that's still in pending), but
the kernel folks have been more aggressive. They found that tr's
pathological flushing was adding minutes to their build times.
Just removing the fflush() made tr significantly faster for my trivial
test, but still slow, with all the time going into stdio. Rewriting the
loop to modify toybuf in place and then do one write per read made most
of the difference, but special-casing the "neither -d nor -s" case made
a measurable difference too on a Xeon.
Bug: http://b/174773617
|
