| Age | Commit message (Collapse) | Author |
|---|
|
This commit introduces the following key changes:
- Support for reading tar archives in formats currently in common use,
such as v7, STAR, USTAR, PAX, and GNU tar's extensions to the
STAR/USTAR format.
- Support for writing PAX archives, only when necessary, using USTAR
when possible for greater portability.
These changes result in lifting of some prior restrictions:
- Support for reading archives produced by modern tar implementations
when other restrictions described below are present.
- Support for filenames which exceed 100 bytes in length, or paths which
exceed 255 bytes (see USTAR format specification for more details on
this restriction).
- Support for filenames of arbitrary length
- Support for unicode metadata (the previous behaviour of erl_tar was
actually violating the spec, by writing unicode-encoded data to fields
which are defined to be 7-bit ASCII, even though this technically
worked when using erl_tar at source and destination, it may not have
worked with other tar utilities, and this implementation now conforms
to the spec).
- Support for uid/gid values which cannot be converted to octal
integers.
|
|
|
|
|
|
|
|
|
|
The reason for this is a requirement on enabling ssh_sftp to write a tar file on the server.
This new api function is used by ssh_sftp:open_tar/3,4.
|
|
The POSIX standard for tar says that there must be at least
two 512-bytes zero blocks at the end of the tar archive file.
Our implementation would only emit a single 512-byte zero block if the
size of the last file was in the range 18*512 through 19*512-1 (modulo
20*512). GNU tar would correctly unpack such tar archive file, but
would emit a warning:
tar: A lone zero block at 20
|
|
|
|
|
|
files as delimiters.
While working on a tool that processes Erlang code and testing it against this repo,
I found out about those little sneaky 0xff. I thought it may be of help to other
people build such tools to remove non-conforming-to-standard characters.
|
|
|
|
|
|
|
|
erl_tar:extract earlier failed when unpacking inside a directory which
had some parent directory to which the user had no read access. This
is corrected.
|
|
|
