pre2.0.7 disk quota bug

[William Jojo]

While we're on the subject of quotas...I have a few questions...(we're running
2.0.6 on AIX 4.3.2)

1) If I map a student's workspace to H: and check Properties, is the quota
supposed to be reported or just the whole filesystem information? When we check
a students H: drive, it reports the whole filesystem info, not quota (which we
would prefer :)

2) If I check properties on a share (read only apps and stuff) - Open M:/select
all/properties, it reports 85,212 files, 3878 folders and on the size line:

	Size:   7.15GB (7,682,881,503 bytes) 27,111,194,624 bytes used

What in the world is that second number?! I'm sure NT is confused (as usual) but
really...

3) We use LZ-based JFS compression on our student filesystems because we get
about 1.82:1 compression and the performance is exceptional. How does this
factor into Samba's reporting of file sizes etc...I think I know the answer to
this and that is it reports the real disk blocks used and not the files true
size...but I've been wrong before.

Bill

jeremy at varesearch.com wrote:
> 
> >
> > 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 ?
> 
> Regards,
> 
>         Jeremy Allison,
>         Samba Team.

-- 


        /------------------------------------------------------\
        |                                                      |
        |                 William E. Jojo, Jr.                 |
        |                                                      |
        |         Senior Systems and Network Specialist        |
        |                                                      |
        |            Hudson Valley Community College           |
        |                                                      |
        |                    (518) 629 7540                    |
        |                                                      |
        |                   jojowil at hvcc.edu                   |
        |                                                      |
        \------------------------------------------------------/


	     We are young wandering the face of the earth

		Wondering what our dreams might be worth

		  Learning that we're only immortal...

			...for a limited time