The get_longfilename() function is called to extract a long (>100 byte)
file name from the tar archive during extract.

If the file name is really long (ie: more than 512 bytes, one tar block),
this loop in client/clitar.c get_longfilename() builds the complete file
name:

    while (left > 0) {
        if (next_block(tarbuf, &buffer_p, tbufsiz) <= 0) {
            DEBUG(0, ("Empty file, short tar file, or read error: %s\n", 
strerror(errno)));
            return(NULL);
        }

        unfixtarname(longname + offset, buffer_p, MIN(TBLOCK, finfo.size), 
first--);
        DEBUG(5, ("UnfixedName: %s, buffer: %s\n", longname, buffer_p));

        offset += TBLOCK;
        left -= TBLOCK;
    }

In particular, the call to unfixtarname() looks dubious for 3 reasons:

 1) "first--" should really be "first" and first should be explicitly set
    to 0 after the call.  Otherwise, if the loop is traversed three times
    (ok, that's a very long path: more than 1024 bytes) then first will
    be non-zero again the third and subsequent times through, and
    unfixtarname() will incorrectly remove a "." if it occurs at
    this point (ie: 1024 bytes into the path).

 2) should MIN(TBLOCK, finfo.size) really be MIN(TBLOCK, left)?  If the
    path length is, eg, 513, then unfixtarname() will be called twice,
    each time with an argument of 512.  That looks like it will overflow
    longname[].  This might be ok since

 3) buffer_p might not be null terminated, and unfixtarname() calls
    safe_strcpy() on it.

I tried to make a test case on WinXP to verify my concerns but couldn't
get past 256 byte paths on NTFS.  I guess I need to setup a test case
with smbd on linux, but I don't have the time right now to set this test
case up.

Apologies in advance for submitting a bug report when I haven't actually
created an example showing the bug...