Bug 3592 - smbclient problem when retrieving locked files >2GB
smbclient problem when retrieving locked files >2GB
Product: Samba 3.0
Classification: Unclassified
Component: smbclient
x86 Windows XP
: P3 major
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2006-03-08 19:55 UTC by Justin Best (mail address dead)
Modified: 2006-04-26 16:27 UTC (History)
1 user (show)

See Also:

Fixes error when retriving locked files > 2GB (133 bytes, patch)
2006-04-19 17:18 UTC, Justin Best (mail address dead)
no flags Details
Proposed patch (3.00 KB, patch)
2006-04-19 19:45 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Justin Best (mail address dead) 2006-03-08 19:55:13 UTC
I'm using Craig Barratt's BackupPC software (see backuppc.sf.net) to back up files from my Windows XP desktops to a Linux machine.

I've got a user whose Outlook PST file is slightly larger than 2GB in size. If Outlook is running, this PST file will be locked by Windows. If this file is locked by Windows when BackupPC tries to back up this particular PST file (via smbclient), I get all kinds of crazy weird characters in the backup log, and the  backup software has fits.

When I contacted Craig Barratt on the issue, here was his response:

"Craig Barratt" writes:

Yes.  It's a bug in smbclient.

The problem is that smbclient emits the tar header (including the
file's size) before it notices the file is locked and cannot be
read.  It's too late at that point to omit the file from the
tar archive.  So it fills the tar archive with dummy data.
BackupPC notices the error message and removes the file,
since it just contains 0x0 data.

Looking at samba 3.0.7 (an old version, but the latest I have
around), samba-3.0.7/source/client/clitar.c does this:

    /* pad tar file with zero's if we couldn't get entire file */
    if (nread < finfo.size) {
        DEBUG(0, ("Didn't get entire file. size=%.0f, nread=%d\n",
                                (double)finfo.size, (int)nread));
        if (padit(data, sizeof(data), finfo.size - nread))
                DEBUG(0,("Error writing tar file - %s\n", strerror(errno)));

and padit() is:

    static int padit(char *buf, int bufsize, int padsize)

Notice the padsize is an int, so above 2GB (your file is just
over 2GB), it is negative!

For a start, if you make padsize an unsigned int then you
should be good to 4GB.  But the real fix is to make padsize's
type SMB_BIG_UINT, which should be 64 bits on most modern
machines.  You should also file a bug and patch with samba.


This my first attempt at filing a bug report anywhere (Yes, I admit it... I'm primarily a Windows guy, though nowadays I'm trying to correct that!).

I'm running the version of smbclient included in the Samba package on Debian Sarge (3.0.14a-3sarge1)
Comment 1 Justin Best (mail address dead) 2006-04-19 17:18:55 UTC
Created attachment 1864 [details]
Fixes error when retriving locked files > 2GB

Patch tested, it does indeed solve the problem. However, because it changes padsize from INT to SMB_BIG_UINT it does create the following warning on compile:

client/clitar.c:566: warning: int format, different type arg (arg 2)

for reference, line 566 is:
        DEBUG(5, ("Padding with %d zeros\n", padsize));
Comment 2 Justin Best (mail address dead) 2006-04-19 17:20:14 UTC
Comment on attachment 1864 [details]
Fixes error when retriving locked files > 2GB

corrects error in clitar.c
Comment 3 Jeremy Allison 2006-04-19 19:45:29 UTC
Created attachment 1865 [details]
Proposed patch

Try this patch instead - it should skip writing the file if the first read failed, plus have the same effect as your patch if it fails later.
Comment 4 Justin Best (mail address dead) 2006-04-26 12:30:55 UTC
(In reply to comment #3)

Thank you so much, Jeremy. The patch you sent worked wonderfully (and also saved me time, because I had network bandwidth being used to transfer 2GB of "zeros" that were being used as padding)

As I mentioned before, I'm new to all this. What do I do now -- mark the bug as FIXED? Or should I leave it be and let you handle resolving it? I want to make sure the code you gave me gets into the current codebase properly, so that some day, I can use the Samba package included with Debian and your fix will be automagically included. Of course, with the speed that the Debian project moves, that's probably about 800 billion years from now...

Thanks so much for your help!
Comment 5 Gerald (Jerry) Carter 2006-04-26 16:27:40 UTC
marking as fixed.  Code has been checked in.