File deletion error on

[Peter tk]

Dear all,

Customer have encountered a problem was that supposed the directory file is deleted successfully:

$ DEL/LOG/NOCONFIRM DIRS$TMP:ZIP_19053219_2081528C.DIR;*
%DELETE-I-FILDEL, DIRS$:[TMP]ZIP_19053219_2081528C.DIR;1 deleted (69 blocks)

but when they performed the backup (command no retrievable), the error message "no such file" is prompted. After that, customer performed the $direct "file", and they found that the file name is appeared again but the timestamp is indicated "no such file". They have to manually delete the directory file again.

What bring my interest that was they are running DFO V2.9; will that be possibly caused by the access conflict (i.e User delete the file while DFO was accessing too. But not sure if it could cause the inconsistency.

Thank you for any "possible reason" so that I could be able to explain to customer.


OpenVMS Alpha V8.2
DFO V2.9

Best regards,
William

[Hoff]

What is the outcome that you expect from this research? Given a specific answer or the identification of the error, what will be the results of gleaning that knowledge? What will be the value? And would there be a better way to spend the time and effort that was involved in the research and in acquiring that knowledge?

If this crops up regularly, then investigate what is happening with the directory, and what operations are occurring in parallel with the deletion. And in "up-armoring" the DCL and related processing involved.

As for the possibilities (and emphasis on possibilities): back links can cause this. disk errors. User errors. Conflicts between the backup and the deletion operations and the defragger or some other application that was running. Bugs in the local DCL. OpenVMS bugs.

And the better response to these questions in general -- where you'll get more return for the investment of time and thought -- is to spend the time that would have been spent figuring this out on:

- a: if the backups are sufficient and complete and current and if the entire configuration can be restored and the environment restarted from the archives. To ensure your customer can recover from disk errors.

- b: if the systems are running current versions for OpenVMS and DFO and all layered products, and to establish more current ECOs and the associated policies and procedures to get to current releases and ECO kits, and to test same.

If this is an actual and unresolved problem (and thus fodder to report to HP), the first thing HP is going to ask is to ECO the box to current. And if you want a more specific response or problem identification here (than the guesses), that's going to be involving HP support directly, or a whole lot more detail here.

[John Gillings]

William,

"Files" are somewhat of an illusion. What you see in a directory is a name pointing to a file header, which in turn points to the data. If you see "no such file" it means there is a directory entry but no file header. For some reason the file data and header have been deleted, but not the directory entry.

Given the long filename, I'd be especially careful to cross check the file name of your deleted file against the problem file to ensure you're really looking at the same entity.

The most common reason for finding dangling directory entries is where there are multiple directory entries for the same file (see SET FILE/ENTER) and the file has been deleted via a different entry. The dangling entry can be removed with SET FILE/REMOVE (dangerous command, see the warning under HELP SET FILE/REMOVE)

It's very unlikely that this could be caused by DFO. Any access conflict would be resolved with by DFO backing off, or the DELETE failing.

[comarow]

It is possible the file was open, but you got it marked for delete. In which case,
when you run anal/disk/repair it will free it up. Have fun.

Bob