[Samba] Bug in 3.6.0 saving files.

[Jeremy Allison]

On Fri, Aug 26, 2011 at 04:15:04PM -0700, Linda Walsh wrote:
> 
> 
> Yes... more than one person has noticed it...
> 
> I think it has to do with SMB2 keeping multiple descriptors open in,
> perhaps, a cache,
> to the same file...
> 
> When Windows writes 'many' (not all), files out, it will first
> 'create' the 'name' of the
> new file to verify access in the target location, then it will write
> the file to a 2nd file
> (xxxx.tmp), and at the end of it all, do a rename.  That way, if
> something interrupts, it,
> you never get a partial file left there, either all or nothin'.
> 
> 
> It's the rename that fails, & win deletes the tmp.
> 
> So when I saw this, I'd see ZERO length files under the name I'd saved,
> and I'd find deleted 'tmp' dirs with the full content in the
> .recycle dir of my SMB share.
> 
> 
> The exact cause I surmise, above, is _speculation_, based on a
> limited understanding
> on some differences that SMB2 seems to allow that normally help
> achieve faster
> overall performance.   But I think samba, is, not seeing those locks
> as 'advisory', but as
> mandatory, so it tells windows that someone has it locked --
> 
> either that, OR Window''s request to release the lock is getting
> lost or perhaps, just
> delayed, so the rename attempts to manip a locked file (thus fail)...
> 
> Obviously speculations on my part as to cause, but you are 3rd
> person to note
> the problem -- cept another noted it with files downloading w/web
> browsers, and I noticed
> it on writing out large image files from photoshop ( files in the
> 1-2+GB range)...

No, it's just a bug in the SMB2 server code, not a client issue.

Note this inside smbd/smb2_setinfo.c:

                if (file_info_level == SMB_FILE_RENAME_INFORMATION) {
                        /* SMB2_FILE_RENAME_INFORMATION_INTERNAL == 0xFF00 + in_file_info_class */
                        file_info_level = SMB2_FILE_RENAME_INFORMATION_INTERNAL;
                        if (fsp->oplock_type != FAKE_LEVEL_II_OPLOCK &&
                            fsp->oplock_type != NO_OPLOCK) {
                                /* No break, but error. */
                                tevent_req_nterror(req, NT_STATUS_SHARING_VIOLATION);
                                return tevent_req_post(req, ev);
                        }
                }

The NT_STATUS_SHARING_VIOLATION error is correct for exclusive oplocks, but
wrong I think for batch oplocks. I'm currently compiling an smbtorture test
case to test this (we already test the exclusive oplock case).

Shame this didn't get caught on the release candidates, but we've
got it now and it'll be fixed in 3.6.1 (along with one other "interesting"
SMB2 bug :-).

More when I've tested and tracked down the specific issue.

Cheers,

Jeremy.