>Is that with or without sys$parse and/or sys$search? What, exactly, gets the error? What happens if you use some other p>rogram (like, say, TYPE or EDIT) to open the same file?

>>> not using sys$parse or sys$search. Using sys$qiow to access (i.e. IO$_ACCESS | IO$M_ACCESS,)

> I didn't find any difference in file properites for file that could be open without any issue and files failed to open.

>> The error refers to the properties of a directory, not the properties of a file which is in a directory.

>>> In the same directory other files are accessible, hence I assumed directory properties are not the issue.

> HELP /MESSAGE BADIRECTORY

>See especially "User Action"

User Action: Use the DCL command SET FILE/NODIRECTORYto delete the corrupt directory file, then use the DCL commandANALYZE/DISK_STRUCTURE/REPAIR to place the lost files in the[SYSLOST] directory. The lost files can then be copied to a new directory.

I couldn't suggest this to my customer as this may cause loss of data.

What does any other DCL command which opens your target file do? (without knowing the type and size of file, I don't know which command(s) are appropriate - ANALYZE/RMS maybe?).

If DCL works and your $QIO code doesn't, what do you think that means?

Look at the directory contents with DUMP/DIRECTORY. Does your target entry look OK?

Remember that directories are just lists of pointers to files. They're really only a convenience for humans. The data is safe, pointed to by the "real" directory INDEXF.SYS. If a directory really is corrupt, you can:

1) Try to patch the file yourself (and since you're asking this question, that's not really an option)

2) Do the right thing - Delete the directory and recover the directory entries with ANALYZE/DISK/REPAIR

If you need further help with this then you should answer the general question on whether the target file can be accessed with other methods, and you should trim down your program to the minimum needed to reproduce the issue and attach it?

Perhaps the program is simply mis-managing the filename descriptor and passing a bad string under certain circumstances?

General question - what does RENAME do if you are moving a file between directories and it can't find the source .DIR?

I imagine that RENAME has to alter the directory backlink (ie. the DID) in INDEXF.SYS, then go and modify the two (i.e. old and new) .DIR files. Or does it do this in a different sequence (e.g. add to new .DIR, remove from old .DIR and then change INDEXF.SYS)?

The reason for my question is that I was wondering if the files in the failed directory have known names and RENAME will be able to insert them into a new directory even if the old directory is broken.

Mind you, we've seen nothing about what DUMP/DIRECTORY displayed, or ANALYZE/DISK and I don't think anyone has inquired about errors being logged for that disk...

If this forum is to be a useful resource then solutions or people's stuff-ups should be reported here so that other people can benefit from the knowledge.