odd tar problem

[adav84]

Hello,
I've noticed that tar behaves strangely - it keeps updating files that haven't been changed when they have several square brackets in their names, like this:

[adav@localhost Desktop]$ mkdir zzz
[adav@localhost Desktop]$ echo test> zzz/dfgsdfg
[adav@localhost Desktop]$ echo test> zzz/sdfg\[
[adav@localhost Desktop]$ echo test> zzz/dfghdfgh\[fghfgh
[adav@localhost Desktop]$ echo test> zzz/sdfg\[sdfgdf\]sdfgf
[adav@localhost Desktop]$ tar cvf foo zzz
zzz/
zzz/dfgsdfg
zzz/sdfg[sdfgdf]sdfgf
zzz/sdfg[
zzz/dfghdfgh[fghfgh
[adav@localhost Desktop]$ tar uvf foo zzz
zzz/sdfg[sdfgdf]sdfgf
[adav@localhost Desktop]$ tar uvf foo zzz
zzz/sdfg[sdfgdf]sdfgf
[adav@localhost Desktop]$ tar uvf foo zzz
zzz/sdfg[sdfgdf]sdfgf
[adav@localhost Desktop]$ uname -a
Linux localhost.localdomain 3.5.0-2.fc17.x86_64 #1 SMP Mon Jul 30 14:48:59 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[adav@localhost Desktop]$ tar --version
tar (GNU tar) 1.26
Copyright (C) 2011 Free Software Foundation, Inc.

Does anyone happen to know what's going on?

[simusphere]

This happens on my system too so it lookes like a bug in tar version 1.26

Everytime you try to do the "tar -uvf" it adds another file to the table of contents as shown with tar -tvf file.tar. When you extract the files, you will find that the file containing the [sometext] in it correctly shows the unupdated file. Unfortunately, the -u option of tar is not working correctly with file names with brackets in them and writes the identical file to the TOC for some odd reason.

[adav84]

Thank you for confirming, I thought for a moment I was going mad, as I haven't been able to google anything up (also, what next, a bug in cp? or true)?

Incidentally, this doesn't seem to be limited to tar 1.26. this happens in CentOS 6, too, with its tar 1.23 and 2.6 kernel. The self-built tair (./configure; make) doesn't do that either. (I've tried diff-ing their straces, but I'm still none the wiser.) And this doesn't happen in Debian-derived distros I've tried under VirtualBox (XUbuntu and Zenix.) I wonder if its some odd dependency or compile-time configuration thing.

[stevea]

Using ltrace it's pretty clear that tar is using fnmatch to compare the file name 'zzz/sdfg[sdfgdf]sdfgf' as pattern, with the tar entry name 'zzz/sdfg[sdfgdf]sdfgf' as string, flags are FNM_FILE_NAME and the result is FNM_NOMATCH. The use of fnmatch with a [...] string is not what we want. So, we can make he problem worse.

[stevea@crucibulum tmp]$ man fnmatch
[stevea@crucibulum tmp]$ rm -rf zzz
[stevea@crucibulum tmp]$ rm foo
[stevea@crucibulum tmp]$ mkdir zzz
[stevea@crucibulum tmp]$ touch zzz/a\[foo]z
[stevea@crucibulum tmp]$ touch zzz/a\[bar]z
[stevea@crucibulum tmp]$ touch zzz/a\[baz]z
[stevea@crucibulum tmp]$ tar cvf foo zzz
zzz/
zzz/a[bar]z
zzz/a[baz]z
zzz/a[foo]z
[stevea@crucibulum tmp]$ tar uvf foo zzz
zzz/a[bar]z
zzz/a[baz]z
zzz/a[foo]z
[stevea@crucibulum tmp]$ tar uvf foo zzz
zzz/a[bar]z
zzz/a[baz]z
zzz/a[foo]z

Problem occurs w/ filenames like 'foo\[bar]baz'


bugzilla.redhat.com it please.

[adav84]

bugzilla.redhat.com it please.

I have now.
Thank you!

====
I think I'll mark this [solved] for now.