More on quotas

[MCCALL,DON (HP-USA,ex1)]

Hi Jeremy,
Something we worked with Microsoft on regarding quotas and Windows NT not
giving an error message when the disk was full; might be of interest in this
discussion, although I know this issue goes beyond this...

Bottom line was that in 2.0.7, copying a file from a WinNT workstation to a
nearly full (or quota nearly full) Samba share could end up with a truncated
file, but no error message on the WinNT workstation.  The microsoft
workaround for this was to disable 'writebehind'.
(see q article
http://support.microsoft.com/support/kb/articles/Q290/8/61.ASP )  We also
discovered that if we responded with an NT error message as opposed to a dos
error message ,that WinNT would then generate the appropriate error on the
workstation, instead of believing the file copy was ok, and leaving the
truncated file out there.

This was occurring because the Nt workstation was setting the offset for the
file with that zero byte SMBWrite(), which, since it didn't write any data,
we reply with success; the next SMBWrite actually writes the data, and once
it fills the FS, we return a disk full error (using SMB status code), but NT
(apparently because of writebehind enabled) ignores it.
We found that by returning the appropriate NT status code, NT WOULD generate
an error and clean up the truncated file.

Don't know how useful this info is to the current discussion, but thought
I'd mention it.

Hope this helps,
Don

-----Original Message-----
From: Jeremy Allison [mailto:jeremy at valinux.com]
Sent: Wednesday, March 28, 2001 11:20 AM
To: Jim McDonough
Cc: samba-technical at samba.org
Subject: Re: More on quotas


Jim McDonough wrote:
> 
> On Win2K and NT:
> Find the old file
> See if the new file exists
> open the old file
> create the new file
> set the new file size (transact2 set file info)
> while not finished {
>   read the old file
>   write the new file : breaks on hard error 39
> }
> close the old file
> close the new file
> 
> NT and 2K do not take care of deleting the old file.  If the server is NT
> instead of samba, it issues a zero-byte write at the end of the file to
> test if there is enough room.  This fails, and then it uses a trans2 set
> file info to cause a delete on close.

At what point in the above sequence does it issue the zero
byte write ? Is that the "set the new file size" call you 
mean, or is it before or after that ? This is important,
as I can easily catch this zero size write and cause the
real filesize to be extended - although there's an inherent
race condition w.r.t. other apps extending the file at the
same time.

Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------