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. Craig ----------------------- 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)
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 on attachment 1864 [details] Fixes error when retriving locked files > 2GB corrects error in clitar.c
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. Jeremy.
(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!
marking as fixed. Code has been checked in.