Bug 9504 - 100-character filenames not extracted properly from tar
100-character filenames not extracted properly from tar
Status: RESOLVED FIXED
Product: Samba 3.5
Classification: Unclassified
Component: Client Tools
3.5.6
All All
: P5 normal
: ---
Assigned To: Volker Lendecke
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-14 15:11 UTC by Bjoren Davis
Modified: 2014-09-18 11:41 UTC (History)
0 users

See Also:


Attachments
Tar file with 2 files in it: one with a 99 character path, the other with a 100 character path (10.00 KB, application/octet-stream)
2012-12-14 15:11 UTC, Bjoren Davis
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bjoren Davis 2012-12-14 15:11:53 UTC
Created attachment 8347 [details]
Tar file with 2 files in it: one with a 99 character path, the other with a 100 character path

I have come across a problem with smbclient 3.5.6 when I use the tar ‘x’ feature.
Pathnames that work out to be 100 characters long are extracted incorrectly:
bash-3.2$ tar tvf ugh.tar
-rw-r--r-- bdavis/Domain Users 137 2012-12-07 13:36:40 a50characterpathnameABCDEFGHIJKLMNOPQRSTUVWXYZABCD/a49characterpathnameABCDEFGHIJKLMNOPQRSTUVWXYZABC
-rw-r--r-- bdavis/Domain Users 138 2012-12-07 13:37:11 a50characterpathnameABCDEFGHIJKLMNOPQRSTUVWXYZABCD/a50characterpathnameABCDEFGHIJKLMNOPQRSTUVWXYZABCD
bash-3.2$ smbclient --version
Version 3.5.6
bash-3.2$ smbclient //XXXXXXX/Temp30Day -U XXXXXX/bdavis
Enter XXXXXX/bdavis's password: 
Domain=[XXXXXXX] OS=[Windows Server 2003 3790 Service Pack 2] Server=[Windows Server 2003 5.2]
smb: \> cd bdavis
smb: \bdavis\> tar x ugh.tar
restore tar file \bdavis\a50characterpathnameABCDEFGHIJKLMNOPQRSTUVWXYZABCD\a49characterpathnameABCDEFGHIJKLMNOPQRSTUVWXYZABC0000644 of size 137 bytes
restore tar file \bdavis\a50characterpathnameABCDEFGHIJKLMNOPQRSTUVWXYZABCD\a50characterpathnameABCDEFGHIJKLMNOPQRSTUVWXYZABCD of size 138 bytes
tar: restored 2 files and directories
smb: \bdavis\> cd a50characterpathnameABCDEFGHIJKLMNOPQRSTUVWXYZABCD\
smb: \bdavis\a50characterpathnameABCDEFGHIJKLMNOPQRSTUVWXYZABCD\> dir
  .                                   D        0  Fri Dec  7 13:44:34 2012
  ..                                  D        0  Fri Dec  7 13:44:34 2012
  a49characterpathnameABCDEFGHIJKLMNOPQRSTUVWXYZABC0000644             137  Fri Dec  7 13:36:40 2012
  a50characterpathnameABCDEFGHIJKLMNOPQRSTUVWXYZABCD             138  Fri Dec  7 13:37:11 2012

                35000 blocks of size 4194304. 10651 blocks available
smb: \bdavis\a50characterpathnameABCDEFGHIJKLMNOPQRSTUVWXYZABCD\> exit

As you can see, the file with the 100 character pathname is extracted with its octal permissions concatenated to the name.
I’m attaching the tar file that I used.
I don’t know if this problem is fixed in a newer release of smbclient.
Comment 1 John Sivak 2013-05-02 14:01:33 UTC
I am experiencing this problem as well.

Using smbclient 3.6.9-141.e16 on CentOS 6.2
Comment 2 Bjoren Davis 2013-05-18 21:48:34 UTC
I've created a bugfix which fixes the problem for me.  I'm sure there's a better way to do it, but I'm submitting this because it works:
diff -cwr samba-4.0.5/source3/client/clitar.c samba-4.0.5-bugfix9504/source3/client/clitar.c
*** samba-4.0.5/source3/client/clitar.c	2012-10-02 01:24:41.000000000 -0700
--- samba-4.0.5-bugfix9504/source3/client/clitar.c	2013-05-18 14:48:36.085777204 -0700
***************
*** 216,221 ****
--- 216,222 ----
  	long chk, fchk;
  	int i;
  	char *jp;
+ 	char termname[NAMSIZ+1];
  
  	/*
  	 * read in a "standard" tar format header - we're not that interested
***************
*** 246,261 ****
  		return -1;
  	}
  
! 	if ((finfo->name = SMB_MALLOC(strlen(prefix) + strlen(hb -> dbuf.name) + 4)) == NULL) {
! 		DEBUG(0, ("Out of space creating file_info2 for %s\n", hb -> dbuf.name));
  		return(-1);
  	}
  
! 	strlcpy(finfo->name, prefix, strlen(prefix) + strlen(hb -> dbuf.name) + 4);
  
  	/* use l + 1 to do the null too; do prefix - prefcnt to zap leading slash */
! 	unfixtarname(finfo->name + strlen(prefix), hb->dbuf.name,
! 		strlen(hb->dbuf.name) + 1, True);
  
  	/* can't handle some links at present */
  	if ((hb->dbuf.linkflag != '0') && (hb -> dbuf.linkflag != '5')) {
--- 247,273 ----
  		return -1;
  	}
  
! 	/*
! 	 * Form a NUL-terminated version of the name.  This is 
! 	 *  necessary because the name in the header need not
! 	 *  end with a NUL.  It can be exactly NAMSIZ characters long
! 	 *  and it appears to blend into the mode string that follows
! 	 *  it.  This is the source of bug 9504 "100-character filenames
! 	 *  not extracted properly from tar".  See
! 	 *  https://bugzilla.samba.org/show_bug.cgi?id=9504
! 	 */
! 	strncpy(&(termname[0]), hb->dbuf.name, NAMSIZ);
! 	termname[NAMSIZ] = '\0';
! 	if ((finfo->name = SMB_MALLOC(strlen(prefix) + strlen(&(termname[0])) + 4)) == NULL) {
! 		DEBUG(0, ("Out of space creating file_info2 for %s\n", &(termname[0])));
  		return(-1);
  	}
  
! 	strlcpy(finfo->name, prefix, strlen(prefix) + strlen(&(termname[0])) + 4);
  
  	/* use l + 1 to do the null too; do prefix - prefcnt to zap leading slash */
! 	unfixtarname(finfo->name + strlen(prefix), &(termname[0]),
! 		strlen(&(termname[0])) + 1, True);
  
  	/* can't handle some links at present */
  	if ((hb->dbuf.linkflag != '0') && (hb -> dbuf.linkflag != '5')) {
Comment 3 David Disseldorp 2014-09-18 11:41:31 UTC
This bug is fixed with Aurélien's rewrite of clitar to use libarchive, which will be released with Samba 4.2