This code in client/clitar.c::writetarheader() only works on little-endian machines: if (size > (SMB_BIG_UINT)077777777777LL) { /* This is a non-POSIX compatible extention to store files greater than 8GB. */ memset(hb.dbuf.size, 0, 4); hb.dbuf.size[0]=128; for (i = 8, jp=(char*)&size; i; i--) hb.dbuf.size[i+3] = *(jp++); } This causes smbclient to fail on big endian machines when creating tar files with >=8GB files. Secondly, client/clitar.c::readtarheader() fails to handle the case of size >= 8GB (ie: hd->dbuf.size[0] == 0x80). It just does this: finfo->size = unoct(hb->dbuf.size, sizeof(hb->dbuf.size)); I will submit a patch for both bugs after I complete some testing (it's slow with such large files).
Created attachment 195 [details] proposed patch Submitted proposed patch. Tested with >= 8GB smbclient tar create. However, smbclient tar extract still only writes a maximum 2GB file; not sure why.
database cleanup
Have there been any recent updates on this ? We're seeing a failure with a 4 GB tarball. 2GB (exactly) is being written to the target, and the following errors are reported: command: -------- smbclient //<target ip>/<share> "<password>" -U <user> -Tx <tarball> errors: ------- Error writing remote file Abandoning restore Sounds a bit like a 32bit counter somewhere. This was tried with the following versions: Version 3.0.3-5 Version 3.0.20b Using smbclient and a "put" of the 4gb tarball works fine.
client/clitar.c seems to be the cause - should the pos,dsize (and possibly bpos) variables be off_t's and not ints ? ---- static int get_file(file_info2 finfo) { /* int fnum = -1, pos = 0, dsize = 0, bpos = 0; existing variable declarations */ /* new declarations */ int fnum = -1; off_t pos = 0, dsize = 0, bpos = 0; SMB_BIG_UINT rsize = 0; DEBUG(5, ("get_file: file: %s, size %.0f\n", finfo.name, (double)finfo.size)); if (ensurepath(finfo.name) && (fnum=cli_open(cli, finfo.name, O_RDWR|O_CREAT|O_TRUNC, DENY_NONE)) == -1) { DEBUG(0, ("abandoning restore\n")); return(False); } /* read the blocks from the tar file and write to the remote file */ rsize = finfo.size; /* This is how much to write */ while (rsize > 0) { /* We can only write up to the end of the buffer */ dsize = MIN(tbufsiz - (buffer_p - tarbuf) - bpos, 65520); /* Calculate the size to write */ dsize = MIN(dsize, rsize); /* Should be only what is left */ DEBUG(5, ("writing %i bytes, bpos = %i ...\n", dsize, bpos)); if (cli_write(cli, fnum, 0, buffer_p + bpos, pos, dsize) != dsize) { DEBUG(0, ("Error writing remote file\n")); ----- from include/proto.h size_t cli_write(struct cli_state *cli, int fnum, uint16 write_mode, const char *buf, off_t offset, size_t size); offset (or pos in clitar.c) should be a off_t and not a int as declared. I'd suspect this is the cause of the 2Gb limit. However my changes result in some 9728 bytes extra being written to the file. These extra bytes seem to be zeros.
Created attachment 2468 test
Created attachment 2469
Created attachment 2470
Created attachment 2471
Created attachment 2472
Created attachment 2473
Created attachment 2474
Created attachment 2475
Created attachment 2476
Created attachment 2477
Created attachment 2478
Created attachment 2479
Created attachment 2480
Created attachment 2481
Created attachment 2482
Created attachment 2483
Created attachment 2484
Created attachment 2485
Created attachment 2486
Created attachment 2487
Created attachment 2488
Created attachment 2489
Created attachment 2490
Created attachment 2491
Created attachment 2492
Comment on attachment 2477
If it's still broken in 3.5, please reopen. 3.0 isn't supported anymore.
This bug is still present in 3.6.
Created attachment 7049 [details] Patch from combining comment 1 and comment 4 proposals Provided by Masafumi Nakayama.
Comment on attachment 7049 [details] Patch from combining comment 1 and comment 4 proposals Looks good.
Created attachment 7224 [details] git-am fix for 3.5.next Back port of the 3.6.x patch above to 3.5.x. David, please confirm then I'll re-assign to Karolin for inclusion in 3.5.next and 3.6.next. Jeremy.
Back port looks good, thanks Jeremy. Karolin, could you please apply the attached patch "git-am fix for 3.5.next" to 3.5.next and cherry pick the master commit (909056a2daacd961b40158b86bc117650a897054) for 3.6.next?
(In reply to comment #36) > Back port looks good, thanks Jeremy. > > Karolin, could you please apply the attached patch "git-am fix for 3.5.next" to > 3.5.next and cherry pick the master commit > (909056a2daacd961b40158b86bc117650a897054) for 3.6.next? Done. Closing out bug report. Thanks!