Conference noted::hackers_v1

   I had that problem once, and I tracked it down to some files that
    were munged up.  with a dir/size, they had a size of 0, but actually
    took up quite a bit of space.  try $ dir/size/full (??) to see how
    many blocks your files *really* take up.
    
    Robb

    I think /size shows you how much is used, not how much is allocated.
    Filesystem overhead (mapping blocks, ...) may also count toward
    you quota under VMS?

    Wow, thanx for there quick replys. (Not even 5 hours).
    When I did a DIR/SIZE/FULL I saw that the majority of the files
    we something like "12/19 blocks" or "32/50 blocks".  I even had
    one that was "0/316 blocks"!!  So now that I located the problem,
    how do I fix it???
    			-=*>Jason<*=-

    As all of us who are old RSX types know the correct DIRECTORY command
    is DIR/SIZ:ALL/DATE.  Looking at the used file size without knowing
    the the allocated size is saving just a few characters on your screen
    and potentially causing the sort of confusion described in .0.
    
    Take a look at the other exciting DIR options like /TOT and /GRAND
    as well.
    
    Have a ball,
    
    Don

SET

  FILE

    /TRUNCATE

     /TRUNCATE

     Requests that the file is to be truncated at the  end  of  the  block
      containing the end-of-file (EOF) mark.

    Well, after trimming EVERYTHING down and setting most of my files
    to truncate I got my dir down to a physical 5711 blocks and my
    quota shows 6449 blocks.  I was thinking, the 738 blocks couldn't
    be missing because I have mail messages because all the mail messages
    are in mail.mai and that is counted in the physical file size.
    
    VMS is STRANGE!!
    -=*>Jason<*=-

    	This gets answered time and time again in Notes file after Notes
    file - it's probably even in here somewhere as well...
    
    	DIR/SIZE=ALL/GRAND [*...]
    
    		or even
    
    	DIR/SIZE=ALL/BY_OWNER/GRAND [000000...]
    
    	will only get you the size taken up by the file itself.  You
    are also charged a minimum of 1 block per file for the file header.
    If your file has multiple headers, then your quota is charged for
    each header.
    
�    		...I got my dir down to a physical 5711 blocks and my
�    quota shows 6449 blocks.  I was thinking, the 738 blocks couldn't
    
    	I'm betting that you own somewhere in the neighborhood of 738
    files....
    
    
    						--Doug    

>   You are also charged a minimum of 1 block per file for the file header.
>    If your file has multiple headers, then your quota is charged for
>    each header.

	Well ... a file header does not take up a whole block. What
	really gets your quotas up is the disk cluster size, set up
	when  you  initialize  your pack. If it's 1, a 1 block file
	will  have  1  block allocated, if it's 16, it will have 16
	blocks  charged  to  your  disk quota. On most systems I've
	seen  it's set to 3 (which is the default for disks capable
	of holding 50.000 blocks or more. ($ HELP INIT DEVICE /CLUSTER_SIZE )

	I think big cluster sizes are to be used on disks with just
	a few, big to HUGE files to improve throughput or so....

	You might also have some files with your UIC hanging around
	in some other directory on the disk. DIR/BY_OWN DISK:[*...]
	will find them for you...

			Marc

    Are you sure file-headers don't take up a whole block?  I thought
    that there was each file-header and extended-file-header was 1 block
    in the INDEXF.SYS file.
    
    /Bevin
    
    PS: No-one's mentioned lost files yet, have they?

    $ dir/size=all/grand [...]

    Grand total of 28 directories, 307 files, 5713/6144 blocks.
     
    $ sh quota
  
    User [SUPPORT,DECARTERET] has 6487 blocks used, 10513 available,
    of 17000 authorized and permitted overdraft of 1000 blocks on USER$4
    
    This is what I got when I did what reply .7 mentioned.  I tried
    everything else in the other replies and everything with a [*...]
    said I had insufficient privilege.  
    Could it be hidden files or lost files or something?
    			-=*>Jason<*=-

    Looks fine to me.
    
    You've got 5713 out of 6144 used because of the disk clustersize,
    most likely 3 (as mentioned in a previous note). A 7 block file
    takes up 9 blocks.
    
    Note that 6144+307=6451 where 307 is the number of files. As previously
    mentioned each file takes up AT LEAST 1 block for the fileheader
    in INDEXF.SYS which is charged to you. We're now talking about a
    piddling discrepancy of 6487-6451=36 blocks.
    
    Now I wouldn't be surprised if that was caused by some files having
    extended headers (ie greater than 1 block). Also I'm not sure if
    the DIR/GRAND takes into account the size of .DIR files. In addition
    you may have files in other people's directories and maybe even
    some lost files that'll only get directoried if somebody does a
    VERIFY/REPAIR on the disk. Is 36 blocks that important to you?
    
    Dave

    Re .10, etc:
    
    Pay attention now;
    	
    	To get a fairly good approximation of your Disk Quota, use the
    	following procedure.  Execute the command 
    		DIR/SIZE=ALL/GRAND DISK$:[000000...]
    	Now you are charged for the total blocks ALLOCATED.  This is
    	larger number that comes after the "/".  IE., in 'ssss/aaaa'
    	the 'ssss' is the size in blocks and 'aaaa' is the allocation
    	in blocks.  Now add 1 block for each file.  This is because
    	you are charged at least 1 block for the file header of each
    	file, which resides in the INDEXF.SYS file on your disk.  This
    	will not show up on the directory command so you have to 
    	estimate it using your total number of files. Large files and 
    	fragmented files might be charged more than one block, but these
    	are usually a small percentage of your total files.
    
    Using your figures:
    
>    $ dir/size=all/grand [...]
>
>    Grand total of 28 directories, 307 files, 5713/6144 blocks.
>     
>    $ sh quota
>  
>    User [SUPPORT,DECARTERET] has 6487 blocks used, 10513 available,

    we have:
    		Total Allocation	6144
    		Number of Files		 307
		+			----
    		Estimated Quota		6451
    		
    		Actual Quota	    -	6487
    					----
    		Discrepency		  36  blocks
    
    The final discrepency of 36 blocks can be easily explained by files
    that have large file headers (more than 1 block).  Personally I
    think that an error of 0.55% (36/6487) is a darn good estimate.
    
    --  Barry

    Oops.  Dave beat me to it.

    	Thanks for all your help.  Now I know what happens to some of
    my disk space!!  It's haunted me for 12 years!  
    
      Re. 11.
    
    Not really, 36 blocks doesn't really bother me at all.

re: Those 36 extra blocks:

Do a DIR/SIZE=ALL [000000]username.DIR, and add a block for this file, if you
haven't already.

-Mike

    You can verify the cluster size for the volume by doing a
    
    	$ show device sys$login/full

Re: .9

>    Are you sure file-headers don't take up a whole block?  I thought
>    that there was each file-header and extended-file-header was 1 block
>    in the INDEXF.SYS file.

	Ooops...  got confused somewhere. Yes, you're right, a file
	header takes up one block, and so does the extension header
	if there is any - I guess I've been thinking only about the
	retrieval  pointers  'cause  of some program i made a while
	back... sorry 'bout that !

		Marc_who_should_have_RTFM_before_starting_to_argue...

      And now, the lost files that weren't mentioned yet.
      
      If there are any files on the disk which are owned by your
      UIC, but aren't in your directories (such as those in other
      directories, or those lost, or those in other directories which
      really are yours, but you forgot about them), those will be
      counted against your disk quota, but will not be counted in
      your directory command.  
      
      You can own files in someone else's directory if they have
      allowed you to write a file there and you did so.
      
      Another discrepancy that can show up is files in your directories
      which are owned by someone else.
      
      Dave C.

>      If there are any files on the disk which are owned by your
>      UIC, but aren't in your directories (such as those in other
>      directories, or those lost, or those in other directories which


One common way of 'losing' files, is to put them in a library, such as CMS or
DTM.

							$+eve

    6144 allocated
     307 file headers for user files
      28 file headers for directories
       1 file headers for top level directory
    ----
    6480 blocks
    
    Your quota used was 6487; wanna bet size of top level dir is 7 blocks?
    

    you probably have a file with an extension header

>    6144 allocated
>     307 file headers for user files
>      28 file headers for directories
>       1 file headers for top level directory
>    ----
>    6480 blocks
    
    Sorry.  The .DIR files are just like any other file, and the space
    they take up counts against the directory they are children of.
    So the `28' doesn't count in the above calculation.  So the actual
    discrepancy is 35 blocks, which is probably consumed by the root
    directory, as earlier pointed out.  Do you have a lot of files in
    your SYS$LOGIN directory?  Definitely check out DIRECTORY /SIZE=ALL
    [-]root-dir.DIR;1 and let us know; I'll bet it is 35 blocks long.
    Be sure to specify the .DIR;1 so that you will be able to see it
    without wildcards.
    
    #ken	:-)}

    re 612.22
    
    	I did what you pointed out and lo and behold, 11/36 came up.
    				-=*>Jason<*=-

    36!  That means you have one block which you are not getting charged
    for.  It is one thing to be cheated, but to cheat!  shame shame