Jan-Benedict Glaw wrote at 15:43 +0200 on Sep 12, 2008: > On Fri, 2008-09-12 15:49:53 +0300, Sergey Poznyakoff <[EMAIL PROTECTED]> > wrote: > > Juan Cordoba <[EMAIL PROTECTED]> 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: > > [EMAIL PROTECTED]:~/fgoo$ tar czf sdf r\\r > [EMAIL PROTECTED]:~/fgoo$ rm -rf r\\r > [EMAIL PROTECTED]:~/fgoo$ rm -rf r\\r sdf > [EMAIL PROTECTED]:~/fgoo$ touch 'r\r' > [EMAIL PROTECTED]:~/fgoo$ ls |xxd > 0000000: 725c 720a r\r. > [EMAIL PROTECTED]:~/fgoo$ tar czf sdf r\\r > tar: r\r: Cannot stat: No such file or directory > tar: Error exit delayed from previous errors > [EMAIL PROTECTED]:~/fgoo$ tar --version > tar (GNU tar) 1.20 > Copyright (C) 2008 Free Software Foundation, Inc. > [...] > [EMAIL PROTECTED]:~/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.
