Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
On Sun, Mar 02, 2014 at 20:19:36 +0100, Markus Steinborn wrote:
> Nowhere it mentions that unquoting is restricted to filenames read
> with -T. From the documentation I'd guess that unquoting applies to
> filenames from the command line, too.
>
>
> With tar 1.27.1 it in fact applies to command line filenames, too -
> in conformance with the texinfo doc, but in conflict with "tar
> --help".
Here's quick patch to remove the mention of "-T" from the
--unquote/-no-unquote entries in "tar --help" and tar.1.
Nathan
Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
diff --git a/doc/tar.1 b/doc/tar.1
index cd133d9..d256a0a 100644
--- a/doc/tar.1
+++ b/doc/tar.1
@@ -839,7 +839,7 @@ Disable the effect of the previous \fB\-\-null\fR option.
Avoid descending automatically in directories.
.TP
\fB\-\-no\-unquote\fR
-Do not unquote filenames read with \fB\-T\fR.
+Do not unquote input file or member names.
.TP
\fB\-\-null\fR
Instruct subsequent \fB\-T\fR options to read null-terminated names,
@@ -867,7 +867,7 @@ unless overridden by environment variable \fBSIMPLE_BACKUP_SUFFIX\fR.
Get names to extract or create from \fIFILE\fR.
.TP
\fB\-\-unquote\fR
-Unquote filenames read with \fB\-T\fR (default).
+Unquote file or member names (default).
.TP
\fB\-X\fR, \fB\-\-exclude\-from\fR=\fIFILE\fR
Exclude files matching patterns listed in FILE.
diff --git a/src/tar.c b/src/tar.c
index ac32f97..cd32379 100644
--- a/src/tar.c
+++ b/src/tar.c
@@ -717,9 +717,9 @@ static struct argp_option options[] = {
{"no-null", NO_NULL_OPTION, 0, 0,
N_("disable the effect of the previous --null option"), GRID+1 },
{"unquote", UNQUOTE_OPTION, 0, 0,
- N_("unquote filenames read with -T (default)"), GRID+1 },
+ N_("unquote input file or member names (default)"), GRID+1 },
{"no-unquote", NO_UNQUOTE_OPTION, 0, 0,
- N_("do not unquote filenames read with -T"), GRID+1 },
+ N_("do not unquote input file or member names"), GRID+1 },
{"exclude", EXCLUDE_OPTION, N_("PATTERN"), 0,
N_("exclude files, given as a PATTERN"), GRID+1 },
{"exclude-from", 'X', N_("FILE"), 0,
Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
On Sun, Mar 23, 2014 at 11:23:09 +0100, Niels Thykier wrote: > On Sat, 22 Mar 2014 at 13:43:31 -0400, Nathan Stratton Treadway wrote: > The tool building the relevant tar file (known as the "data.tar") would > be dpkg-deb. I am not entirely sure, but I think [1] reflects the tar > command-line it uses, which would be: > > execlp(TAR, "tar", "-cf", "-", "--format=gnu", "--null", "-T", "-", > "--no-recursion", NULL); > > I guess that is where the (missing) "-T" appears that caused us headaches. Yes, exactly. (This is originally invoked somewhere as "dpkg-deb --build [DIR]", where DIR points to the directory tree being populated by the "echo foo" commands, right?) > > Are you sure there was a change in behavior of the test between tar > > 1.27 and 1.27.1? > > Yes. We experienced a behaviour change in 1.27 and we adapted the code > and tests accordingly (e.g. [2] and [3]). Now we are seeing it change > again with 1.27.1. For reference, tar 1.27 landed in Debian unstable > 2013-10-15. Right, given that -T is indeed involved, this makes sense. > > For reference, the test in [2] does have 3 files created via (Makefile > syntax): > echo foo > debian/tmp/usr/share/doc/filenames/bokml > echo foo > debian/tmp/usr/share/doc/filenames/bokm\\l > echo foo > debian/tmp/usr/share/doc/filenames/bokml > (If anyone else wants to find this, those lines are at: http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=blob;f=t/tests/legacy-filenames/debian/debian/rules#l95 ) > Accordingly, when I saw the test output change and compared it what the > test was doing, I thought the test had been wrong all this time and tar > finally fixed it. Namely, I would expect the above to create the > following 3 files on the file-system > > O1 bokmål(6 chars long) > O2 bokm\ål (7 chars long) > O3 bokm\\ål (8 chars long) Right. > If I understand the situation correctly, then these 3 files are passed > to tar (with -T --null) via dpkg, causing them to be "unqouted". This > reduces the number of unique names to (per [4]): > > T1 bokmål (6 chars long, T1 is O1 in the tarball) > T2 bokmål (6 chars long, should have been O2, but in tar it is > a hardlink of T1) > T3 bokm\ål(7 chars long, T3 is O3 in the tarball) Yes, exactly. > T1, T2 and T3 is (as I understand you and other people on this mailing > list) the correct, expected behaviour when the tarball is built as: > >tar -cf - --format=gnu -null -T - --no-recursion > Well, I guess the point is that it _is_ the expected behavior of that tar command, but it does not produce the "correct" result in this case. That is, assuming that the "echo" commands in debian/rules really do produce the three unique files on the filesystem as expected, the "true" failure here is that when dpkg-deb is generating a data.tar file that does not accurately mirror the contents of the debian/tmp/... directory tree. By "luck" tar 1.27 generated an actually-correct "data.tar" archive, thus tipping you off that your test cases were originally written to expect the incorrect archive contents However, as Sergey explained earlier in this thread, the tar 1.27 unquoting behavior wasn't intended, and it was changed back to match long-term behavior in 1.27.1. > and if I want the paths named O1, O2 and O3 to appear in the tarball > (rather than T1, T2 and T3), I need to either pass --no-unquote (not an > option here) or add one more level of quoting? So, I think that means that dpkg-deb has been (and is again) liable to generate incorrect data.tar archives for packages that have unusual filenames in them. (It may be that this doesn't actually happen much outside lintian test cases, but the point is that if any actual source package did try to create have such files the resulting .deb wouldn't contain the expected filenames...) I don't know much about dpkg-deb's internal workings, but off hand I'd say that it needs to either pass the --no-unquote option when spawning tar or to quote the path names that it passes to the tar subprocess... (If in fact the problem does occur during the "dpkg-deb --build" step, I don't think there's any quoting that you can add yourself to correct the problem...) Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
> On Sun, Mar 02, 2014 at 12:55:34 +0100, Bastien ROUCARIES wrote: >> Hi, >> >> newer tar (1.27.1)has a serious regression compared to 1.27. > > > On Sat, Mar 22, 2014 at 10:33:56 +0100, Bastien ROUCARIES wrote: >> Yes they should be indeed treated literally. I use shell completion >> and it is pretty natural to get the name as is. > > Can you give us more information about how tar is actually being called > by lintian? (I found Debian bug #740199, but it doesn't give any > details about the actual tar command being used by the test or in what > manner it's failing.) > Hi, (Please ensure I am CC'ed on replies as I am not subscribed to this list) For the given tests, lintian does not build the tarball causing this issue. So it would "only" call tar in the following ways: dpkg-deb --fsys-tarfile | tar tvf - | \ sort -k 6 | gzip --best -c > index.gz dpkg-deb --fsys-tarfile | tar --numeric-owner -tvf - | \ sort -k 6 | gzip --best -c > index-ids.gz dpkg-deb --fsys-tarfile | tar xf - -C unpacked The tool building the relevant tar file (known as the "data.tar") would be dpkg-deb. I am not entirely sure, but I think [1] reflects the tar command-line it uses, which would be: execlp(TAR, "tar", "-cf", "-", "--format=gnu", "--null", "-T", "-", "--no-recursion", NULL); I guess that is where the (missing) "-T" appears that caused us headaches. > Are you sure there was a change in behavior of the test between tar > 1.27 and 1.27.1? Yes. We experienced a behaviour change in 1.27 and we adapted the code and tests accordingly (e.g. [2] and [3]). Now we are seeing it change again with 1.27.1. For reference, tar 1.27 landed in Debian unstable 2013-10-15. > As mentioned earlier in this thread, the unquoting > behavior of file names mentioned in a -T file did change between those > two versions, but the behavior for filenames specified on the command > line shouldn't have changed... (And even for -T, the behavior in > 1.27.1 should match the behavior of earlier versions other than 1.27 > itself.) > For reference, the test in [2] does have 3 files created via (Makefile syntax): echo foo > debian/tmp/usr/share/doc/filenames/bokml echo foo > debian/tmp/usr/share/doc/filenames/bokm\\l echo foo > debian/tmp/usr/share/doc/filenames/bokml Where is less's way of showing an unrepresentable character, lintian uses "?" instead - the charecter is an å in (I think) ISO-8859-1. Accordingly, when I saw the test output change and compared it what the test was doing, I thought the test had been wrong all this time and tar finally fixed it. Namely, I would expect the above to create the following 3 files on the file-system O1 bokmål(6 chars long) O2 bokm\ål (7 chars long) O3 bokm\\ål (8 chars long) If I understand the situation correctly, then these 3 files are passed to tar (with -T --null) via dpkg, causing them to be "unqouted". This reduces the number of unique names to (per [4]): T1 bokmål (6 chars long, T1 is O1 in the tarball) T2 bokmål (6 chars long, should have been O2, but in tar it is a hardlink of T1) T3 bokm\ål(7 chars long, T3 is O3 in the tarball) T1, T2 and T3 is (as I understand you and other people on this mailing list) the correct, expected behaviour when the tarball is built as: tar -cf - --format=gnu -null -T - --no-recursion and if I want the paths named O1, O2 and O3 to appear in the tarball (rather than T1, T2 and T3), I need to either pass --no-unquote (not an option here) or add one more level of quoting? ~Niels [1] http://anonscm.debian.org/gitweb/?p=dpkg/dpkg.git;a=blob;f=dpkg-deb/build.c;h=2871234a09ed31bcc83865cdf4f0f71a504f0d62;hb=db9051cc21519459b7552f5d04d2465386d0b772#l602 [2] http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=commitdiff;h=80f4060ec58262f2cd261fe9677f8de71fb411dd;hp=135f2c1f4ec6556a6e84a5eb533ee0429c7bfc5b [3] http://anonscm.debian.org/gitweb/?p=lintian/lintian.git;a=commitdiff;h=952d64558a25df127f19d08875b4f8996cb4e6e3 [4] http://lists.gnu.org/archive/html/bug-tar/2014-03/msg00018.html
Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
On Sat, Mar 22, 2014 at 6:43 PM, Nathan Stratton Treadway wrote: > On Sun, Mar 02, 2014 at 12:55:34 +0100, Bastien ROUCARIES wrote: >> Hi, >> >> newer tar (1.27.1)has a serious regression compared to 1.27. > > > On Sat, Mar 22, 2014 at 10:33:56 +0100, Bastien ROUCARIES wrote: >> Yes they should be indeed treated literally. I use shell completion >> and it is pretty natural to get the name as is. > > Can you give us more information about how tar is actually being called > by lintian? (I found Debian bug #740199, but it doesn't give any > details about the actual tar command being used by the test or in what > manner it's failing.) > > Are you sure there was a change in behavior of the test between tar > 1.27 and 1.27.1? As mentioned earlier in this thread, the unquoting > behavior of file names mentioned in a -T file did change between those > two versions, but the behavior for filenames specified on the command > line shouldn't have changed... (And even for -T, the behavior in > 1.27.1 should match the behavior of earlier versions other than 1.27 > itself.) I have reproduced manually the test by running tar command. The command are run by dpkg in order to create debian package. I could check the source if needed, but they are clearly a behavior change in the command line between the two versions. Bastien >> >> Could you give us a solution in either way ? > > As also mentioned earlier in the thread, adding the --no-unquote option > to the "tar -cf test.tar *" invocation should produce the behavior you > were expecting in the example commands you gave in your original email > -- but if that's necessary for the lintian test to succeed when using > tar 1.27.1, I am not sure why the test wasn't failing in the same way > with pre-1.27 versions > > Nathan > > > Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region > Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ > GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 > Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
On Sun, Mar 02, 2014 at 12:55:34 +0100, Bastien ROUCARIES wrote: > Hi, > > newer tar (1.27.1)has a serious regression compared to 1.27. On Sat, Mar 22, 2014 at 10:33:56 +0100, Bastien ROUCARIES wrote: > Yes they should be indeed treated literally. I use shell completion > and it is pretty natural to get the name as is. Can you give us more information about how tar is actually being called by lintian? (I found Debian bug #740199, but it doesn't give any details about the actual tar command being used by the test or in what manner it's failing.) Are you sure there was a change in behavior of the test between tar 1.27 and 1.27.1? As mentioned earlier in this thread, the unquoting behavior of file names mentioned in a -T file did change between those two versions, but the behavior for filenames specified on the command line shouldn't have changed... (And even for -T, the behavior in 1.27.1 should match the behavior of earlier versions other than 1.27 itself.) > > Could you give us a solution in either way ? As also mentioned earlier in the thread, adding the --no-unquote option to the "tar -cf test.tar *" invocation should produce the behavior you were expecting in the example commands you gave in your original email -- but if that's necessary for the lintian test to succeed when using tar 1.27.1, I am not sure why the test wasn't failing in the same way with pre-1.27 versions Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
On Sun, Mar 2, 2014 at 8:33 PM, Sergey Poznyakoff wrote: > Hi Markus, > >> Nowhere it mentions that unquoting is restricted to filenames read >> with -T. From the documentation I'd guess that unquoting applies to >> filenames from the command line, too. > > Yes, indeed, the unquoting is applied to names obtained from the command > line as well, and as I said in my previous post that's the way tar > operated at least since v. 1.13. > >> So what behavior is intended? > > My feeling is that unquoting file names obtained as arguments is rather > pointless. They should indeed be treated literally. Although this can > easily be fixed (see the attached patch), I'm afraid that the fix itself > might break compatibility with some existing applications that use tar. Yes they should be indeed treated literally. I use shell completion and it is pretty natural to get the name as is. Could you give us a solution in either way ? Bastien > Regards, > Sergey >
Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
On Mon, Mar 03, 2014 at 07:19:23 +0200, Sergey Poznyakoff wrote: > from a file supplied with the -T option, not the ones listed in the > command line. The latter were handled as always. To wit: > > $ ls --quoting-style=literal > \ \\ > $ tar --version|head -1 > tar (GNU tar) 1.27 > $ tar cfv ../2.tar * > \\ > \\ I didn't quite understand why tar was giving that output until I ran the experiment myself. In case anyone else following this thread was wondering, what's actually happening here is that the file called "\" on the filesystem (and "\\" by tar) is getting added to the archive twice, and the one called "\\" on the filesystem isn't included at all: $ tar --version | head -1 tar (GNU tar) 1.27.1 $ ls -l total 8 -rw-r--r-- 1 nathanst nathanst 5 2014-03-04 00:00 \ -rw-r--r-- 1 nathanst nathanst 10 2014-03-04 01:00 \\ $ tar -cvf test.tar * \\ \\ $ tar -tvf test.tar -rw-r--r-- nathanst/nathanst 5 2014-03-04 00:00 \\ hrw-r--r-- nathanst/nathanst 0 2014-03-04 00:00 \\ link to \\ $ mkdir extr $ cd extr $ tar -xvf ../test.tar \\ \\ $ ls -l total 4 -rw-r--r-- 1 nathanst nathanst 5 2014-03-04 00:00 \ Adding "--quoting-style=literal" to the tar command line (or "--quoting-style=escape" to the ls command line) reduces the confusion a little (on the output side). $ tar --quoting-style=literal -tvf ../test.tar -rw-r--r-- nathanst/nathanst 5 2014-03-04 00:00 \ hrw-r--r-- nathanst/nathanst 0 2014-03-04 00:00 \ link to \ $ ls -l --quoting-style=escape total 24 -rw-r--r-- 1 nathanst nathanst 5 2014-03-04 00:00 \\ -rw-r--r-- 1 nathanst nathanst10 2014-03-04 01:00 (On the input side, "tar --no-unquote -cvf test.tar *" does successfully include both files in the archive, as mentioned elsewhere in this thread.) Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
On Mon, Mar 03, 2014 at 07:19:23 +0200, Sergey Poznyakoff wrote: > Hi Nathan, > > > Just to be clear, version 1.27 did behave differently from the earlier > > versions, and then 1.27.1 was released in order to change the behavior > > back to match the earlier versions. > > Not quite so. The bug you are referring to affected file names read > from a file supplied with the -T option, not the ones listed in the > command line. The latter were handled as always. To wit: Ah right, thanks for that clarification. Bastien's original post specifically mentioned a change between 1.27 and 1.27.1, so I wonder if the initial lintian breakage he experienced was actually triggered by the change in -T behavior between those two versions. (But I don't know enough about lintian internals to know off hand if -T actually does come into play...) Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
Hi Nathan, > Just to be clear, version 1.27 did behave differently from the earlier > versions, and then 1.27.1 was released in order to change the behavior > back to match the earlier versions. Not quite so. The bug you are referring to affected file names read from a file supplied with the -T option, not the ones listed in the command line. The latter were handled as always. To wit: $ ls --quoting-style=literal \ \\ $ tar --version|head -1 tar (GNU tar) 1.27 $ tar cfv ../2.tar * \\ \\ Regards, Sergey
Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
jOn Sun, Mar 02, 2014 at 21:24:32 +0200, Sergey Poznyakoff wrote: > Hi Bastien, > > > newer tar (1.27.1)has a serious regression compared to 1.27. > > It's not a regression -- all tar versions back to 1.13 behaved > exactly the same. Just to be clear, version 1.27 did behave differently from the earlier versions, and then 1.27.1 was released in order to change the behavior back to match the earlier versions. For the details: the topic was discussed here on this list last October and November: http://lists.gnu.org/archive/html/bug-tar/2013-10/msg00045.html http://lists.gnu.org/archive/html/bug-tar/2013-11/msg2.html , and in the 1.27.1 release notes: http://savannah.gnu.org/forum/forum.php?forum_id=7792 Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
Hi Sergey, Sergey Poznyakoff schrieb: My feeling is that unquoting file names obtained as arguments is rather pointless. They should indeed be treated literally. Although this can easily be fixed (see the attached patch), I'm afraid that the fix itself might break compatibility with some existing applications that use tar. Regards, Sergey Well, I'd prefer fixing that (if someone likes to fix it) by making --no-unquote the default. That leaves the caller the option to enable unquote if needed.I haven't had the case, but it might be that you want to give filenames with unprintable characters as an option, and in this case unquoting might be usefull. Anyway, "tar --help" should be fixed to describe tar's behavior. Greetings Markus
Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
Hi Markus, > Nowhere it mentions that unquoting is restricted to filenames read > with -T. From the documentation I'd guess that unquoting applies to > filenames from the command line, too. Yes, indeed, the unquoting is applied to names obtained from the command line as well, and as I said in my previous post that's the way tar operated at least since v. 1.13. > So what behavior is intended? My feeling is that unquoting file names obtained as arguments is rather pointless. They should indeed be treated literally. Although this can easily be fixed (see the attached patch), I'm afraid that the fix itself might break compatibility with some existing applications that use tar. Regards, Sergey >From 499b05e2855c954527819757077321b5b030e6e4 Mon Sep 17 00:00:00 2001 From: Sergey Poznyakoff Date: Sun, 2 Mar 2014 21:14:39 +0200 Subject: [PATCH] Don't unquote file names received from the command line. * src/names.c (name_next_elt): Don't unquote NELT_NAME content. --- src/names.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/names.c b/src/names.c index 9fc0ad5..88163d5 100644 --- a/src/names.c +++ b/src/names.c @@ -589,8 +589,6 @@ name_next_elt (int change_dirs) /* fall through */ case NELT_NAME: copy_name (ep); - if (unquote_option) - unquote_string (name_buffer); entry.type = ep->type; entry.v.name = name_buffer; name_list_advance (); -- 1.7.12.1
Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
Hi Bastien, > newer tar (1.27.1)has a serious regression compared to 1.27. It's not a regression -- all tar versions back to 1.13 behaved exactly the same. Regards, Sergey
Re: [Bug-tar] Fwd: [regression] tar mess up \ and \\ files
Hi,
Bastien ROUCARIES wrote
bastien@bastien-debian:/tmp/testcase$ ls
'\ \ \\
bastien@bastien-debian:/tmp/testcase$ tar -cf test.tar *
bastien@bastien-debian:/tmp/testcase$ tar -tf test.tar
'\\
\\
\\
Well, things are more complicated:
tar --no-unquote -cf test.tar *
works as expected. "tar --help" tells us:
--no-unquote do not unquote filenames read with -T
--unquote unquote filenames read with -T (default)
whereas the texinfo manual says:
@item --no-unquote
Treat all input file or member names literally, do not interpret
escape sequences. @xref{input name quoting}.
@item --unquote
Enable unquoting input file or member names (default). @xref{input
name quoting}.
@anchor{input name quoting}
By default @GNUTAR{} attempts to @dfn{unquote} each file or member
name, replacing @dfn{escape sequences} according to the following
table:
Nowhere it mentions that unquoting is restricted to filenames read with
-T. From the documentation I'd guess that unquoting applies to filenames
from the command line, too.
With tar 1.27.1 it in fact applies to command line filenames, too - in
conformance with the texinfo doc, but in conflict with "tar --help".
So what behavior is intended?
Greetings
Markus Steinborn
