| Age | Commit message (Collapse) | Author |
|---|
|
* emj/stdlib/tar-repro/PR-1608/OTP-14834:
Add options for creating reproducible tars
Return error when unable to make dir
|
|
|
|
'tar_entry()' values are only returned if we specify the 'verbose'
option when calling table/2, which table/1 doesn't do.
Now, it appears that Dialyzer as of OTP 20 is clever enough to realize
that the return type of table/1 must intersect with the return type of
table/2, and so it ignores the fact that table/1 says it returns
strings, and therefore its callers are expected to be dealing with
'tar_entry()' tuples, and never with strings.
This is obviously a mismatch between what the code does and what the
spec says is does, leading to false Dialyzer warnings on code that uses
table/1 (and, presumably, also table/2 when called without
the 'verbose' option.)
|
|
|
|
Since aa0c4b0df7cdc, erl_tar would write the local time (instead of
the POSIX time) into the tar header for the archived files. When
extracting the tar file, the extracted file could be set to a future
time (depending on the time zone).
We could do a minimal fix, but this seems to be a good time
to rewrite the time handling to use the new features that
allow file info to be read and written in the POSIX time
format.
First reported here: https://github.com/erlang/rebar3/issues/1554
|
|
|
|
Also let the test suite verify that all files that are
opened will be closed before the end of each test case.
aa0c4b0df7cdc7 introduced the file descriptor leak.
|
|
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.
|
|
|
