The fix from commit 8632df398b2f548465ebe68b8f494c0d6f8d913d is
also required for tests/Makefile.am:
LDADD = ../gnu/libgnu.a\
$(LIB_ACL) $(LIB_CLOCK_GETTIME) $(LIB_EACCESS)\
$(LIB_GETRANDOM) $(LIB_HARD_LOCALE) $(FILE_HAS_ACL_LIB) $(LIB_MBRTOWC)\
- $(LIB_SELINUX) $(LIB_SETLOCALE_NULL)
+
As OpenBSD packager for GNU tar, I was contacted by a user who ran
into a problem with 1.34: Accessing a remote device is now only
possible as superuser. Otherwise, tar will error out with
initgroups: Operation not permitted
initgroups(3) is indeed limited to the superuser. The initgroups()
Commit 1ff0b63f4898 "Accept only position-sensitive (file-selection)
options in file list files" has introduced a pointer indirection
bug that breaks TAR_OPTIONS parsing.
The problem shows up when running the test suite on FreeBSD 12.2
where it can be simplified to this reproducer:
$ export
There is a regression in tar 1.33 on OpenBSD. Thanks to Stefan Hagen
for figuring out the details.
89: extracting even when . and .. are unreadableFAILED (extrac09.at:37)
The key part of the test:
mkdir dir
mkdir dir/sub
mkdir dir/sub/extract
genfile --file dir/sub/f
cd
GNU tar 1.31's regression test #162 (sparse07.at) fails on FreeBSD
11 and 12.
This has nothing to do with sparse files. It concerns unicode file
names in general. The underlying problem appears to be a difference
between GNU iconv() and FreeBSD's iconv(). For a conversion from
UTF-8 to ASCII,
GNU tar 1.31's regression test 41, numeric.at, is broken on filesystems
with BSD semantics (GID inherited from directory) if run in a
directory whose GID does not match the primary GID of the executing
user.
I already reported this problem for 1.29 and 1.30. A fix had been
suggested for 1.29,
On FreeBSD 11, I see this regression test failure with GNU tar 1.30:
156: sparse files with unicode names FAILED (sparse07.at:24)
See the testsuite.log at the end of this message.
This has nothing to do with sparse files. It concerns unicode file
names in general. The
Sergey Poznyakoff:
> > For GNU tar 1.30, the regression tests remfiles01.at and remfiles02.at
> > (175 176) fail.
>
> Pretty strange, but both tests work for me (the release would have been
> impossible if they woudn't). Any specific conditions in order to
> reproduce that?
It fails for me on
For GNU tar 1.30, the regression tests remfiles01.at and remfiles02.at
(175 176) fail. The immediate problem is that tar's child process
fails to identify itself as "tar (child)" in the error message.
The underlying cause is a change in gnulib, specifically this commit:
In the tar 1.30 release there was a problem with the difflink.at
test; this has been fixed in HEAD. However, the test still fails
on *BSD and there is an underlying portability issue.
The preparatory part of the test runs this:
mkdir a
genfile -f a/x
ln -s x a/y
ln a/y a/z
What is the expected
The numeric.at test is broken on filesystems with BSD group semantics.
I already reported this for 1.29 and this fix was suggested:
https://lists.gnu.org/archive/html/bug-tar/2016-06/txt9bP0DVvYnu.txt
Alas, it hasn't found its way into 1.30.
--
Christian "naddy" Weisgerber
There is a small distribution issue with GNU tar 1.30. Since
doc/version.texi is out of date with respect to doc/stamp-vti,
the *.info files are always rebuilt from the *.texi sources.
This obviously fails is makeinfo is not available or too old.
--
Christian "naddy" Weisgerber
Pavel Raiskup:
> Then we should be able to switch the group ownership back to $GID, does
> the attached patch help?
-snip-
Yes, this looks correct... and successfully fixes the test.
--
Christian "naddy" Weisgerber na...@mips.inka.de
In GNU tar 1.29, this new regression test
30: numeric.at:18 --numeric-owner basic tests
is itself broken on filesystems that have BSD group inheritance,
i.e., where a newly created file gets the group of the directory
rather than that of the user.
Obviously, this affects (at least) all
(Replying to Nathan Treadway; I'm not subscribed to this list.)
mkdir foo
mkdir bar
echo foo/foo_file foo/foo_file
echo bar/bar_file bar/bar_file
decho A
tar -cvf foo.tar --remove-files -C foo . -C ../bar .
decho B
find .
Do you happen to still have tar 1.27.1
So you are on a system that has gettext in an extra libintl (and
possibly libiconv, too). You want to link tar statically, say for
recovery purposes, but you don't want to drop NLS support. How do
you do this?
(1) You configure with LDFLAGS=-static. You expect this to do the
trick.
(2) The
Paul Eggert:
If I understand things correctly, src/extract.c's extract_file
is invoking open_output_file, which returns -1 with errno==ELOOP.
extract_file then should invoke:
maybe_recoverable (./file1, true, interdir_made)
maybe_recoverable should execute this code:
if
On FreeBSD 7.3, test #39 extract over symlinks fails. Specifically,
it's this snippet of extrac13
ln -s target1 dst2/file1
echo target1 dst2/target1
tar --overwrite -xf archive.tar -C dst2 --warning=no-timestamp
that errors out:
tar: ./file1: Cannot open: Too many links
ktrace shows
Paul Eggert:
The relevant shell source code (in testsuite) is:
# Tar should work when there are few, but enough, file descriptors.
((ulimit -n 10
tar -cf archive3.tar a 3- 4- 5- 6- 7- 8- 9-
tar -xf archive3.tar -C dest3 a 3- 4- 5- 6- 7- 8- 9-
)
diff -r a dest3/a /dev/null 21
)
Paul Eggert:
One other thing. Can you please replace all instances
of ((ulimit -n with ( (ulimit -n in tests/testsuite?
This fixes a portability bug in that script that may
be relevant to the OpenBSD shell. This reflects the
following patch that I just pushed:
When called as ksh,
Paul Eggert:
Ah, OK. Does the following output buggy shell, then?
if (ulimit -n 10; : -) 2/dev/null
then echo OK
else echo Houston we have a problem
fi
Houston we have a problem on
OpenBSD 4.8 (and older versions, nothing has changed there)
FreeBSD 7.3
FreeBSD 8.1
--
Christian naddy
Running the GNU tar 1.24 testsuite (make check) on OpenBSD, I get
three failures:
34: extrac09.at:22 no need to save dir with unreadable . and ..
36: extrac11.at:23 scarce file descriptors
53: listed03.at:22 incremental dump when the parent directory is unreadable
#34 and #53 fail because
The gnu/fdopendir.c included with GNU tar 1.24 won't compile with a C89
compiler because it puts a declaration in between statements.
--- gnu/fdopendir.c.origTue Oct 26 06:54:19 2010
+++ gnu/fdopendir.c Tue Oct 26 06:54:52 2010
@@ -116,6 +116,7 @@ fdopendir_with_dup (int fd, int
There is a stupid, stupid bug in FreeBSD 7 (up to and including the
7.3 release): The fdopendir() function is present in libc, but the
prototype is missing from dirent.h.
GNU tar's configure picks up fdopendir(), but since there is no
prototype, it ends up typed as
int fdopendir();
This is
Sergey Poznyakoff:
The junk-fill malloc() debugging function on BSD reveals that there is
some sort of use-after-free() bug in 1.23.
Thanks. Please apply the attached patch.
Yes, this fixes it.
--
Christian naddy Weisgerber na...@mips.inka.de
For 1.23, the link02 and link03 regression tests misleadingly fail
on OpenBSD, because that platform doesn't provide a link(8) command.
Is there a good reason not to use ln(1)?
--- tests/link02.at.origThu Mar 25 16:17:52 2010
+++ tests/link02.at Thu Mar 25 16:18:07 2010
@@ -34,9 +34,9
The junk-fill malloc() debugging function on BSD reveals that there is
some sort of use-after-free() bug in 1.23.
Specifically, if you run the test suite with MALLOC_OPTIONS=J set,
test 44 (incr06) fails because tar dumps core.
(gdb) bt
#0 strcmp (
s1=0x20392a0c0
Sergey Poznyakoff:
The junk-fill malloc() debugging function on BSD reveals that there is
some sort of use-after-free() bug in 1.23.
To analyze this, I need to know the exact command line used to invoke
the tar. What were the options used?
tar -c -f archive-1.1.tar -g db.1 -C dir -v
noordsij:
Dear GNU tar maintainer(s) / fBSD gtar port maintainer(s),
The problem appears to be a difference in getline() behaviour in the fBSD
and GNU libc.
So fBSD libc looks at the value of linecapp, whereas GNU libc looks at the
value of lineptr, to determine whether to allocate a new
GNU tar 1.19 fails to build on FreeBSD 8-CURRENT (starting from
2008-03-31). The problem is code in lib/getcwd.c and lib/savedir.c
that mistakenly assumes if openat() is available, so will be
fdopendir(). FreeBSD imported the Solaris-style *at() functions,
but it does not have fdopendir(), and I
Sergey Poznyakoff:
really correct? It has been forwarded to me as a security fix for
1.18, but there it causes tar to hang when trying to extract any
symlink from an archive. This can easily be confirmed by running
the test suite.
The test suite works for me. Any ways to reproduce?
The T-null regression test erroneously fails on OpenBSD (and probably
some other platforms as well). The problem is that the expected
output string
...
[jeden\ndwa
trzy
],
...
is passed on to the echo(1) command in the generated testsuite script:
echo $at_stdout; echo jeden\\ndwa
trzy
|
In tar 1.15.92, tests/shortrec.at still assumes that tar was built with
DEFAULT_ARCHIVE=- (stdin/out).
--- tests/shortrec.at.orig Fri Oct 20 17:35:12 2006
+++ tests/shortrec.at Fri Oct 20 17:35:28 2006
@@ -28,7 +28,7 @@ AT_KEYWORDS([shortrec.at])
AT_TAR_CHECK([
mkdir directory
(cd
33 matches
Mail list logo
