23 Dec
2017
23 Dec
'17
11:44 p.m.
Somewhat tangentially related to the other thread...
So, back in the days when I was using Consensys SVR4.2, I found a bug in
tar. It goes like this:
If there is a symbolic link in the tree that you are taring, the first
one works fine. If a second symbolic link has a shorter destination name
than the first, the extra characters from the first symbolic link
destination are appended to the end of the second. So for example:
a -> abcdef
b -> zyx
Tar will actually tar these symbolic links as:
a -> abcdef
b -> zyxdef
Being that I happen to have found, on the Internet, the sources to AT&T
SVR4.2, and some other System V variants, I went and investigated.
The relevant piece from AT&T SVR4.2 tar.c (broken):
Jan 25 1993 ./ATT/ATT-SYSVr4/cmd/tar/tar.c
case S_IFLNK:
<SNIP>
i = readlink(shortname, filetmp, NAMSIZ - 1);
if (i < 0) {
vperror(0, "can't read symbolic link %s",
longname);
return;
}
From USL-4.2 (apparently fixed):
Jan 22 1994 ./USL/usl-4.2-source/src/i386/cmd/tar/tar.c
case S_IFLNK:
<SNIP>
i = readlink(shortname, filetmp, NAMSIZ - 1);
if (i < 0) {
vperror(0, ":462:Cannot read symbolic link %s",
longname);
return;
}
else
filetmp[i] = '\0'; /* since readlink does not
supply a '\0' */
From Solaris 2.5:
case S_IFLNK:
<SNIP>
i = readlink(shortname, filetmp, NAMSIZ - 1);
if (i < 0) {
vperror(0, gettext(
"can't read symbolic link %s"), longname);
if (aclp != NULL)
free(aclp);
return;
} else {
filetmp[i] = 0;
}
BSD 4.4:
case S_IFLNK:
<SNIP>
i = readlink(shortname, dblock.dbuf.linkname, NAMSIZ - 1);
if (i < 0) {
fprintf(stderr,
"tar: can't read symbolic link %s: %s\n",
longname, strerror(errno));
return;
}
dblock.dbuf.linkname[i] = '\0';
Anyone know when/why/how tar diverged between the two branches? Note the
readlink directly into dblock.dbuf, while the SVR4 variants use a temp
string and then sprintf it in later.
From: http://www.catb.org/esr/faqs/usl-bugs.txt
17. tar(1) fails to restore adjacent symbolic links properly
Arthur Krewatt <...!rutgers!mcdhup!kilowatt!krewat> reports:
SVR4 tar has another strange bug. Seems if when restoring files, you
restore one file that is a link, say "a ->/a/b/c/d/e" and there is another
link just after it called "b ->/a/b/c" tar will restore it as "b
->/a/b/c/d/e"
This just seems to be a lack of the NULL at the end of the string, like
someone did a memmov or memcpy(dest,src,strlen(src)); where it should be
strlen(src)+1 to include the NULL.
Esix cannot reproduce this under 4.0.4 or 4.0.4.1, they think it's fixed.