NT_STATUS_DISK_FULL in response to SMB_COM_CLOSE

[Jeremy Allison]

On Tue, Mar 09, 2010 at 06:24:04PM +0100, Mathijs Brands wrote:
> Hello,
> 
> I'll get right to the point: is ERRdiskfull/NT_STATUS_DISK_FULL valid
> in a Close response?
> 
> Some additional info:
> 
> We have a RHEL 5.2 server (Samba 3.0.28) which allows users to access
> their UNIX homedir from Windows. The data itself is stored on a NetApp
> and mounted by AutoFS.
> 
> When a user reaches his (block) quota on the NetApp, Samba returns
> NT_STATUS_DISK_FULL. This happens either in a SMB_COM_CLOSE or
> SMB_COM_WRITE_ANDX response.
> 
> SMB_COM_CLOSED returns NT_STATUS_DISK_FULL if the close() call returns
> EDQUOT. SMB_COM_WRITE_ANDX returns NT_STATUS_DISK_FULL a the pwrite()
> call returns EDQUOT. Which one occurs seems to depend on timing.
> 
> If the write returns NT_STATUS_DISK_FULL, Explorer pops up a warning
> that the copy failed and it deletes the file. The user knows it went
> wrong and can take action to rectify the situation, such as deleting
> some files.
> 
> If the close returns the write, Explorer seems blissfully unaware of
> the fact the file could not be written completely and it does not
> inform the user of this failure, nor does it remove the file. The user
> now has a file of the right size and with the right date/time, but
> without the correct contents. For the user this will show up as 'data
> corruption' (blocks that were not written are read back as all-zeroes).

Yes, IMHO this is a bug in the Windows redirector that is never
triggered by Windows servers as they do pre allocation (so
they never return disk full on close).

> Our current work-around is to enable 'strict allocate', but this causes
> twice as much writes to the NetApp. Samba use ftruncate to get a sparse
> file of the right size and then uses write() calls with 4k data to fill
> the file.

Sorry, that's the only way to get 100% Windows behavior - you must
allocate the file in a non-sparse way.

Jeremy.