Re: [Bug-tar] tar-1.20 and filepaths containing "\r"

[John Hein]

Jan-Benedict Glaw wrote at 15:43 +0200 on Sep 12, 2008:
 > On Fri, 2008-09-12 15:49:53 +0300, Sergey Poznyakoff <address@hidden> wrote:
 > > Juan Cordoba <address@hidden> ha escrit:
 > > 
 > > >    This is using GNU tar 1.20:
 > > [...]
 > > >    $ tar cvf z.tar z\\r
 > > >    tar: z\r: Cannot stat: No such file or directory
 > > 
 > > I cannot reproduce this. Running this command with tar 1.20 correctly
 > > adds z\r to z.tar.
 > 
 > I was able to reproduce it with 1.16 as well as with 1.20:
 > 
 > address@hidden:~/fgoo$ tar czf sdf r\\r 
 > address@hidden:~/fgoo$ rm -rf r\\r 
 > address@hidden:~/fgoo$ rm -rf r\\r sdf 
 > address@hidden:~/fgoo$ touch 'r\r'
 > address@hidden:~/fgoo$ ls |xxd
 > 0000000: 725c 720a                                r\r.
 > address@hidden:~/fgoo$ tar czf sdf r\\r 
 > tar: r\r: Cannot stat: No such file or directory
 > tar: Error exit delayed from previous errors
 > address@hidden:~/fgoo$ tar --version
 > tar (GNU tar) 1.20
 > Copyright (C) 2008 Free Software Foundation, Inc.
 > [...]
 > address@hidden:~/fgoo/tar-1.20/src$ dpkg -l tar | tail -1
 > ii  tar                               1.20-1                          GNU 
 > version of the tar archiving utility
 > 
 > 
 > If you strace it, you see that the '\r' decoded to ^M and that's what
 > gets lstat()ed in the end. So the filename is probably send through
 > unquote_string().  My initial fear was that the supplied filename is
 > taken as a printf format argument, but on the first glance, I cannot
 > see how you could exploid unquote_string(), despite not backing up
 > some files (or restoring them.)

The failure is reproducible for me, too, with bash or csh, bsd or
linux, from gtar 1.13.25 through gtar 1.20.  bsdtar works fine.