[Info-vax] Empty blocks in FILES-11 directory files.

[abrsvc]

On Saturday, September 24, 2022 at 7:47:38 PM UTC-4, Mark Daniel wrote:
> I'll just refine my query in the bright light of the new day. 
> 
> Dan has clarified the "Empty blocks should only exist at the end of the 
> directory file". I seem to recall this shuffle myself. Can someone 
> point to, or reference a resource which confirms this definitely. This 
> would mean my code could quit after the first empty block encountered 
> without continuing on to EOF. This also would imply that without 
> intervention, directory files will not shrink, only grow in size. 
> 
> PS. There are a number of resources out there that do not seem to 
> clarify the issue of these zeroed blocks. (Links posted as quotations 
> to stop them being broken.) 
> 
> > http://www.bitsavers.org/pdf/dec/vax/vms/training/EY-F575E-DP_VMS_File_System_Internals_1990.pdf 
> > https://web-docs.gsi.de/~kraemer/COLLECTION/VMS/ods2.txt 
> > https://groups.google.com/g/comp.os.vms/c/SU2YvPOeowo 
> 
> and an interesting (but not immediately relevant) first-person recollection 
> 
> > https://www.youtube.com/watch?v=b0YenelPw-Y
> On 25/9/2022 3:01 am, Mark Daniel wrote: 
> > It seems as if directory blocks containing zero file entry records, and 
> > subrecords, tend to accumulate in active directories.  Can only assume 
> > these arise when multi-multi-multiversion consecutive file names are 
> > deleted from the directory.  Recently encountered 32 consecutive empty 
> > blocks at which my code sanity checked. 
> > 
> > Quick solution; create an equivalent directory and copy from the 
> > original to the new.  Problem Solvered.  Assume a backup-restore would 
> > accomplish similar, etc. 
> > 
> > Questions: 
> > 
> > Is this expected directory file behaviour? 
> > 
> > Do these empty blocks continue to accumulate, only to be reused should 
> > in-order file names be created? 
> > 
> > Do extensive empty directory blocks represent tangible overhead to the 
> > (persumably) XQP?  (My code sanity checked at 32 but who knows exactly 
> > how many there really were.) 
> > 
> > Are their tools to measure such directory file efficiency (shall we say) 
> > and to "compress" such files (apart from backup-restore). 
> > 
> > TIA, Mark. 
> > 
> > PS. I do recall descriptions of the FILES-11 directory internals being 
> > very simple-minded and inefficient. 
> > 
> > PPS. My entire technical hard-copy collection, including such VMS tomes 
> > as McCoy's File System Internals, in a fit of pique, went into a recycle 
> > bin some years ago.  Moral of the story; don't let line-management get 
> > under your skin. 
> 
> -- 
> Anyone, who using social-media, forms an opinion regarding anything 
> other than the relative cuteness of this or that puppy-dog, needs 
> seriously to examine their critical thinking.
To be honest, I don't know if the contiguous requirement is still valid.  I got that from the Mccoy book.  I will check further and look for the "end" record for the entire directory file. I assume that there is one.

Dan