pre2.0.7 disk quota bug:

[Sanders, Peter]

	Since an 'over-quota' or 'disk-full' message is being sent from
Samba to
the client, it seems obvious that the client _should_ be passing this info.
on to the user -- but it isn't.  One possible way to get this info. to the 
client is for Samba to call a shell script similar to the 'preexec' options
if
quota is exceeded. The script could then invoke smbclient to send a
WinPopUp message to the client.
	Myself, I use the 'preexec' and 'postexec' options to call login and
logout scripts from the [homes] share.  The login script (amongst other
tasks) constructs a message showing the users current disk usage and
quota and uses smbclient to send this to the client as a  WinPopUp
message.
	As I've said before on this list, Samba should have the option to
call
a script for every significant sharing event, including opening and closing
files, entering and leaving subdirectories etc.

>>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
>
>On 2/2/00, 2:25:10 PM, <jeremy at varesearch.com> wrote regarding Re: 
>pre2.0.7 disk quota bug:
>
>
>> >
>> > Hi all,
>> >
>> > SAMBA pre2.0.7
>> > /configure --with-quotas
>> > Linux 2.0.36
>> > The old disk quota bug is still here. If user tries to write the file
>> > to SAMBA share and disk quota is exceeded, SAMBA fills remaining space
>> > within the target file with spaces, and writes it to the share. This
>> > is "xcopy" behavior. If the program writes small chunks of file, the
>> > result may differ. The user is under impression the file was written
>> > successfully. While the file is heavily corrupted!
>> >
>> > Please, sort this out!
>
>> It isn't Samba that is doing this, it is the client.
>
>> The problem occurs because the client sets the file
>> size before doing the writes. Under UNIX, this is allowable
>> sa it creates a file full of "holes" (zeros) that takes no
>> space, so the user has not gone over quota. When the client actually
>> tries to fill the file with real data the user goes over quota and
>> Samba returns an error. But the file size was set *before* the writes,
>> so still seems correct.
>
>> The only way to fix this would be to do an explicit user quota
>> check on every file size change, which would be very expensive
>> (read - *SLOW* !).
>
>> Samba *is* returning the over quota error to the client.
>
>> What tdo you execpt us to do here ?
>
>
>Thanks for reply, Jeremy and for the hints. 
>Since the problem is more complicated, than I expected - I didn't 
>follow the code - I'll try to come up later with some real stuff - 
>suggestions, proposals (code?).
>
>Regards, Sergei.
>



------------------------------