[Samba] Quota / OpLock file truncation again

[Jeremy Allison]

On Fri, Jun 23, 2006 at 04:02:29PM -0700, Marc Jacobsen wrote:
> I am seeing a potentially serious bug with samba 3.0.22 on Linux (Ubuntu 
> Dapper Drake).  I found the following old discussions about the same 
> problem:
> 
> http://lists.samba.org/archive/samba-technical/2004-September/037328.html
> 
> and
> 
> http://lists.samba.org/archive/samba/2003-July/071081.html
> 
> as well as this old closed bug in bugzilla:
> 
> https://bugzilla.samba.org/show_bug.cgi?id=679
> 
> I couldn't find when or if the problem in the second discussion got 
> resolved, and I couldn't find an open bug in bugzilla.
> 
> Anyway, what I am seeing is that with quotas turned on in Linux, and 
> OpLocks enabled on Samba, if you open a file on a client with notepad, 
> expand it past where the quota will allow, then save it, there is no 
> error message.  The client will see the file as the size it expected, 
> but any data past the quota limit is NULL.  If you turn off OpLocks and 
> do the same thing the save will fail and give an error popup window.
> 
> If you set "strict allocate" the only difference is that you won't have 
> the NULL data past the quota limit, the file will just be truncated at 
> the quota limit.  But notepad will not give an error on save, leaving 
> the user ignorant of the file truncation, and data loss.  This sounds 
> just like what was described in the second discussion from above.
> 
> Wordpad and other applications don't exhibit the same behavior.
> 
> So I see three possibilities.  There is a workaround (like setting 
> "strict allocate") that I am not aware of.  Or Samba has regressed and 
> this old bug came back.  Or the bug was only fixed for other apps like 
> Wordpad, but it has always been an overlooked bug with notepad.  I can't 
> believe that a bug like this would be left in Samba intentionally.
> 
> Can anybody please fill me in?

I'm guessing that the quota reporting might be broken
on your system. On open creation Windows commonly does 
a trans2setfilepathinfo setting the allocation space for
the file. Get a network trace from notepad to see if
it does this on save. Commonly to return "out of space"
conditions Windows apps expect this call to fail in the
right way.

This (in Samba) calls down to vfs_allocate_file_space()
which will only test for space if "strict allocate" is set to
true. This calls down to get_dfree_info() which calls down
to sys_disk_free() which returns the number of 1K blocks
free on the disk. This depends on the underlying quota
system working.

You can test this by creating a custom dfree command that
always returns an amount too small for the file and see if
notepad errors out correctly. If it does but not on the
real call then there's a problem interfacing with the
underlying quota code.

Jeremy.