Re: -current tar(1) breakage

[RVP <rvp%SDF.ORG@localhost>]

On Sat, 27 Mar 2021, Hauke Fath wrote:

> [...]
> Reading symbols from /bin/tar...
> Reading symbols from /usr/libdata/debug//bin/tar.debug...
> [New process 10317]
> Core was generated by `tar'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  0x00007f0a03467866 in _citrus_iconv_convert
> (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98,
> out=0x7f7fff902d90,
>    inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at
> /usr/src/lib/libc/citrus/citrus_iconv.h:61
> 61		_DIAGASSERT(cv && cv->cv_shared && cv->cv_shared->ci_ops &&
> (gdb) bt
> #0  0x00007f0a03467866 in _citrus_iconv_convert
> (nresults=0x7f7fff902d18, flags=0, outbytes=0x7f7fff902d98,
> out=0x7f7fff902d90,
>    inbytes=0x7f7fff902d88, in=0x7f7fff902d80, cv=0x7f0a057c40e0) at
> /usr/src/lib/libc/citrus/citrus_iconv.h:61
> #1  _iconv (handle=handle@entry=0x7f0a057c40e0,
> in=in@entry=0x7f7fff902d80, szin=szin@entry=0x7f7fff902d88,
> out=out@entry=0x7f7fff902d90,
>    szout=szout@entry=0x7f7fff902d98) at
> /usr/src/lib/libc/iconv/iconv.c:97

This iconv() trace is very misleading. The bug triggered by the
NFS server returning 0 for .f_namemax in a statvfs() call.

Fix:
---START---
diff -urN a/libarchive/dist/libarchive/archive_read_disk_posix.c b/libarchive/dist/libarchive/archive_read_disk_posix.c
--- a/libarchive/dist/libarchive/archive_read_disk_posix.c	2019-07-24 13:50:23.000000000 +0000
+++ b/libarchive/dist/libarchive/archive_read_disk_posix.c	2021-03-31 12:01:37.437510048 +0000
@@ -1713,7 +1713,7 @@
 		t->current_filesystem->noatime = 0;

 	/* Set maximum filename length. */
-	t->current_filesystem->name_max = sfs.f_namemax;
+	t->current_filesystem->name_max = (sfs.f_namemax == 0) ? NAME_MAX : sfs.f_namemax;
 	return (ARCHIVE_OK);
 }

---END---

Isn't the NFS server supposed to return NFS_MAXNAMLEN?

-RVP