Exceeding block quotas on ext2/3 truncates files when copied from Windows
Explorer to Samba share. This is _without_ error message on the client.

Tests where done with Win98SE and W2k, Samba 2.2."3a" from Debian Woody, and
this one from http://us2.samba.org/samba/ftp/Binary_Packages/Debian/samba3

test@blackhole:~$ /usr/sbin/smbd -V
Version 3.0.0-Debian

Libraries and other stuff are from Debian woody. I used "old" quota version with
"quota.user" as accounting file. Kernel is a 2.4.22 with quota support compiled
in. More info available on request.

How to reproduce:
Copy a file to a samba share that exceeds file system size or block quota. The
server file system needs support for sparse files to get truncation (only ext2/3
tested). So it does _not_ show on vfat. Exceeding inode quota correctly refuses
creation of the new file.

Reason for this behaviour is the way Windows explorer checks for free space
while copying:
1) An empty file is created and return code checked. Verified by trying to
exceed inode quota.

2) "seeking" to position of the last byte to be copied and writing it. Return
code is correctly checked by explorer. Test by copying via Explorer a 2 MB file
to a shared vfat floppy. Error message on client is correct. Using an ext2
floppy silently fails. This step creates a "sparse" file when possible. As the
blocks that are seeked over are not used on disk, the quota system can't account
for them and allows writing the last byte.

3) write all data. This is _not_ error checked on the client side. As smbd has
to obey quota/fs size the data gets truncated.

What to do?
- There is no way to disallow sparse files via a mount option.
- There is no "open" flag "NO_SPARSE".
+ Document that mismatch IN BOLD LETTERS
+ Special case the smb seek operation if size=0 to write out all blocks