From:	MERC::"uunet!CRVAX.SRI.COM!RELAY-INFO-VAX" 18-MAR-1993 01:08:30.21
To:	INFO-VAX@SRI.COM
CC:	
Subj:	Re: Directory not empty. How to delete it?

First, in preface, I want to reassure Richard Gilbert (and others)
that this is not a "serious" problem.  It doesn't indicate a major
problem with the XQP, so don't panic.

Harry Flowers wrote:
	...
>which is the way we get rid of these, too.  For some reason SAS work
>directories seem to corrupt easily; maybe they're doing direct writes
>to the DIR files or something?  I don't know, but we occasionally have
>to delete them for users, and it only happens with the SAS work dirs.
>I wish that whatever SAS was doing to cause it, they'd stop!  Anyway,
>for now, you're stuck with the above solution.  Now, if DEC could just
>fix the problems with ANA/DISK/REPAIR crashing our VAXes, we might be
>able to clean up the drives after this happens (still with 5.5-2).

I chose to reply to Harry's posting, not because I mean to pick on him,
but because it was his comments about SAS that forced my hand, so to
speak.  :)

I thought that I had posted a note about this last year, but apparently
I didn't.  I, too, have had to get rid of these SAS work directories
numerous times.  A couple of years ago, I called SAS and asked them
what the problem was.  In my case, I *only* saw this happen with SAS
work directories.  Furthermore, it seemed that when I DUMPed the
blocks allocated to the directory, they were always filled with C
source code.  So, I contacted our SAS technical support to find out what
the heck they were doing!  Anyway, it got back to (one of) the VMS
developers -- I think it was Tom Cole that I spoke with.  He assured
me that they were using standard VMS services to create the work
directories.  (See, I wondered if they were doing it "by hand".)

(Oh, yeah.  SAS provides some utility (ZCLEANUP?) to get rid of an
old work directory.  The problem is that it doesn't work in these
cases.  SAS said that they had had an occasional report of this,
but never saw it themselves.    *THIS MAKES SENSE, given a little
more information.)

So, I called back to DEC, and was initially told that SAS must be
doing something wrong.

Is this enough of a preface?  OK.  Let's skip the rest of the finger
pointing.  :)

I managed to get a hold of one of the users (who managed to create
several of these directories), and learned something about her "style"
of computing.  Apparently, the user would issue the SAS command, and
then realize that she had forgotten to do something else first, and
so she would abort SAS via a ^Y.   Once she told me that, I was able
to produce corrupt directories with ease.

(See, the folks at SAS.COM probably never abort out of SAS right away.)

[Come on, Derek, get to the *POINT*!]

(OK)

The upshot is that there is a window of vulnerability in the directry
creation process.  (It isn't atomic.)  The file header is allocated
and initialized *BEFORE* the data blocks are written.  I guess because
directories are maintained by the XQP and not by RMS, the EOF data
for a directory is "not accurate".  (DUMP/HEADER one of your directories
some time.  My small directory (1/3) has an EOF block of 2, and a FFB of 0.
The actual data ends at (1,0B6), as determined by the FFFF word.)

So, if you manage to abort the dirtectory creation process between the
time that the directory header is written and the time that the data
blocks are initialized (to NULLs, by the way), you will produce this
condition.  (Try it!  Just do a few CRE/DIRs in a row, and abort
it, you can make these without having to buy SAS!  :))

FIX?  What fix?!  I suggested to the DEC CSC person that he submit a
SPR on my behalf suggesting that the header be initialized SANS the
"is a directory bit" set, initialize the data blocks, and *then*
the the "is a directory" bit.   He said he would, but he doubted that
any work would be done.  This, too, makes sense.  Except in the case
of SAS (or something like it), folks usually INTENTIONALLY create
directories.  Normally, one wouldn't abort the creation, so normally
this window doesn't cause a problem.

What could SAS do?  Put in code to ignore ^Y during the directory
creation.  Will they do this?  I don't know.  They apparently didn't
after I suggested it before.  Maybe if enough of us complain...

-Derek S. Haining
 University Computing Services
 University of Washington
 Seattle, Washington  98195 
 (206) 543-5579

 DEREK@MAX.BITNET
 DEREK@MAX.U.WASHINGTON.EDU