Apart from potentionally leaking malloced memory on error,
which isn't too bad since we immediately exit afterwards,
we were leaving all opened files dangling, as fclose() was never called.
This lets it deal with tar archives that are packaged like this:
usr/include/hello.h
usr/include/bye.h
usr/lib/libexample.a
Instead of requiring directory entries:
usr/
usr/include/
usr/include/hello.h (etc)
This helps since some tar archives (our own example tool, pack, for example, does this) are packaged without directory entries.
First we're saying "reads up to max" and then "always reads up to metadata.size, regardless of max".
We actually mean that we never read more than metadata.size, so that's what this patched text says.
Sure, 256 characters might fit in 'path', but because of the way
paths are stored in a tar archive, basenames cannot exceed 100
characters. So, adding space for a null-terminator, this reduces
our 'name' field from 128 bytes to 101.
This change is backwards-compatible since any reasonable application
should not depend on the name field being 128 bytes (this was never
mentioned in any documentation, API.md describes it as 'char[]' without
a fixed length). sizeof(metadata.name) should always be used instead.
This uses a new struct (struct minitar_w).
This struct is initialized using the minitar_open_w function, and deleted using minitar_close_w.
The functions to write to an archive are minitar_write_file_entry() and minitar_write_special_entry().
The difference is that regular files have content, while the rest (special entries) do not.
This commit also adds a new example program (pack), which can create tar archives from files (no directory support though).
Archives created using pack and minitar can be read and extracted using GNU tar!!
Documentation is coming in another commit.
