Failure to delete an open file

[peterbh]

VMS 6.2 running on a Charon Vax emulation.
A file that has been opened by file id returns a status value of rms$_mkd (failed to mark file for deletion) with fab$l_stv set to 0910 (no such file) when issuing a close with delete.
The file is clearly open at time of issuing the close (as I can see it using $ana/sys $sho proc/chan) and is subsequently closed
Any ideas to determine why this is happening would be much appreciated

[Thomas Ritter]

How about pasting some of the results ? Is the file being managed by a program ? Example ?

[Hoff]

The usual trigger for these involves bugs in the software.

I've seen bugs latent in VMS itself for twenty-five or more years, and similar bugs latent in applications that otherwise appeared to be running "correctly".

Moving to a different (and usually also faster) box has a long history of exposing these bugs.

And sometimes the platform move caused folks to look at the application, and to notice the error(s).

Debug the source code. There's a reasonable likelihood that the errors are correct, of course. If you don't have the source code (as is one reason for emulation) then you may have a (bigger) problem.

OpenVMS back in this era also had the occasional bug around handling temporary files; there was a particularly nasty one with spooled files back in this version range, and I recall a few others. See of your ECOs are "current" for OpenVMS VAX V6.2.

[Hein van den Heuvel]

First and foremost. Did it ever work?

Secondly, does it work on more recent OpenVMS versions. Try on EISNER or DEATHROW?

Does it work with say BYPASS privs?

Is the file deleted?
Does it have a name? (Directory entry)

Maybe the system is trying to protect you from creating an orphan?

anyway...

$CLOSE with FAB$V_DLT translates to a $QIO, IO$_DELETE | IO$M_DELETE.
It tells the QIO to access by FID, unless the file was opened TMP, indicating that there would not be a directory entry. So if RMS knows there is no directory entry, it avoids using the FID. That's a little counter intuitive to me, but it may just match your observations.

If you can single step the code, then stop it just before the $CLOSE and use ANAL/SYSTEM .. SHOW PROC/RMS=(FAB,FWA).
Watch out for FAV$V_ASY. That has caught a good few folks by surprise.
Check the FIB (from the FWA).

Maybe I have time tonight for a reproducer, but if you can isolate the code into an example to be attached, then that would help a lot!

Good Luck!
Hein.

[peterbh]

Hi Folks, thanks for your responses
In reply
Yes, the program has worked and does work on newer and older versions of VMS.
Privileges is not an issue as I am running with BYPASS privilege
The file does not have a name (directory entry) and does not get deleted.
The code is basically opening a file by id, then searching a directory for a file with matching ID (which on this occasion it never finds) and then marking the file for delete before closing it. If I disable the directory search then the delete succeeds. At this stage I am suspecting some sort of buffer overrun in the directory search code
Once again thanks
Peter

[John McL]

Peter, are you using a search path to the directory that you are looking up?

We've seen some funnies with wildcard file look ups where we use a logical name to define a search path. In our case we were seeing duplications of file names.

[peterbh]

Not using a search path. Think I've isolated the problem, we use a pool of FAB's and the same FAB is being used for both the directory search and the Open of the hidden file, I now suspect some debris from the search is being left in the FAB. (I was incorrect earlier about the order, the wildcard search is done first, and then the open and delete)
Peter

[peterbh]

Does anyone know the significance of nam$b_did_nmx ?

In my situation, this is being set (to 5) in the nam block following a $PARSE operation.
Subsequent to this I do a $SEARCH,$OPEN AND $CLOSE, however if the close is a close with delete, then the delete fails as in initial question

Peter

[Hoff]

nam$b_did_nmx? Sure. That's a sub-field of the three-word FID structure for the directory.

The FID and DID values should each be treated as opaque three-word values for the purposes of manipulation and - if one or both are not treated as an opaque three-word value -- well, that would be an application bug.

Near as I can tell, GNV blew the handling of the NMX field, too: <>

[Hein van den Heuvel]

Hoff, is that not node 1023 on your site?

DID_NMX is the Directory file ID sub fields for the directory file NuMber eXtension.
It is the most significant byte for the file number.
It is a documented output for $PARSE.

You can verify with $ DIRECTORY /FILE xxx.DIR
or F$FILE("xxx.dir","FID")

The 5 suggests you'll see a number between 327680 and 400000.

fwiw,
Hein.