| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
"xz compressed data" was missing a newline. Also switch a couple of
other unnecessary (but correct) xprintf calls over to xputs.
Also add .otf fonts, perf/simpleperf data files, and Android boot
images, sparse images, and device tree blobs/overlays.
|
|
file now shows the target of a symbolic link and calls out broken
symbolic links.
file now shows the device type for block/character special files.
file now shows specific reason when it can't open.
stat now includes the device type, plus a little more space between the
number of blocks and the human-readable file type.
Adjusted tests accordingly, which actually makes more of them pass on
the host as a convenient side-effect, but I actually made these changes
because I've been finding the desktop file and stat output more convenient
in these cases.
|
|
|
|
Commit 9448c33944651c1644ffbd0f52cf9d43cae19599 broke ELF note parsing,
because the bounds checking was off. Fix that but also generalize it so
that we won't need note-specific bounds checking in future.
|
|
It's in the Linux 5 kernel headers. If, like me, you'd never heard of
it:
https://www.phoronix.com/scan.php?page=news_item&px=C-SKY-Approved-Last-Arch
|
|
It's in the Linux 4.20 kernel headers.
|
|
Be consistent about upper versus lower case. (Upper seems to have the
majority, so I went with that, though I'm happy to provide the opposite
patch as long as we're consistent!)
Be consistent about using \t. (Though saving a few bytes seems like it
might be better done in the code that generates help.h rather than
directly in the source, since tabs make careful ASCII art layout hard
enough that we regularly have things misaligned.)
Remove trailing periods (most of which seem to have been added by me).
Always use the US "human readable" rather than my British
"human-readable", and be more consistent about declaring whether we're
showing multiples of 1000 or 1024.
Just say "verbose" rather than adding a useless "mode" or "output".
|
|
There are a bunch of if (!memcmp(s+28,...)) lines,
let's make them "else if"
|
|
I've had added the argument, but I don't know what it wants? Ubuntu's file
calls a bmp file "data".
|
|
|
|
|
|
|
|
sh_size>file length test inside the loop and changing the vars to unsigned.
|
|
|
|
|
|
|
|
More of the files encountered on the Android system image (plus PE
executables, which we build but which shouldn't actually make it to the
system image!).
|
|
The Nexus Player build was subtly broken in that it assumed that the host was
using ELF. No-one noticed until a Mac user tried to flash their build, which
contained a Mach-O x86 binary instead of an ELF x86 binary. Hilarity ensued.
(On the same day, file(1) was able to explain a mixup with an ELF hexagon
binary. Next time we see a Mach-O binary on an Android device, we'll be ready!)
Bug: http://b/66741960
|
|
|
|
Everyone forgets that mmap returns MAP_FAILED rather than NULL on failure.
Every use of mmap in toybox was either doing the wrong check, or no check
at all (including the two I personally added).
|
|
|
|
isn't obviously useful.)
|
|
If we can read and write bzip2 files, we should be able to identify them
too...
|
|
An ELF file with no program headers is valid, and binutils leaves e_phentsize
zero in that case. Fix the corruption check to cope.
Also, since notes are in both the program and section headers (and I'm not
aware of the possibility of having no sections but still having notes ---
where would they be?), look for them in the section headers instead.
Also extend the parsing of the .android.note.ident ELF note to include the
NDK version information if present. (This won't be present for platform
binaries, but will be present for NDK-built binaries such as app libraries.)
|
|
|
|
On a toybox system, most of your bin directory is symbolic links.
Bug: http://b/31294746
|
|
then reading from stdin if it detected a file). Fixed it so "-" always
means stdin and you have to say ./- to look at a local "-".
Did some whitespace tweaks while I was there...
|
|
They're really just arbitrary byte sequences of arbitrary length.
Sure, a 20-byte sequence is _probably_ a SHA-1, but there's no way
to know, so let's stop pretending...
|
|
|
