Unable to open file getting -SYSTEM-W-BADIRECTORY, bad directory file format.

[allin-in-one]

Than you.

I will try your suggestions and let you know the outcome.

[Hein van den Heuvel]

btw... my favourite reason to use QIO to access a fiel is to be able to use:

fib.fib$l_acctl = FIB$M_NOLOCK;

>> and resultant-filespec was passed to sys$qiow.

Device and all?

What do you do with the DEVICE from the file-spec?

Do you properly assigne a channel?

Using SYS$PARSE i typically use somthing like:

devnam_desc.addr = nam.nam$l_dev;
devnam_desc.len = nam.nam$b_dev;
if (((status=sys$assign(&devnam_desc,&channel,0,0,0)) & 1) != 1) lib$stop(status);

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?

Hein

[John McL]

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. 

[John McL]

What you might be trying to say but saying badly is that the RENAME will have to access the .DIR file to find the file's FID so that it can locate the entry in INDEXF.SYS.

That would make sense.  How else could it get the FID?

[allin-in-one]

Accessing file using DIR/full  X.Dir  or editing the file having no issues.

Some other applications could access the file for backup.

But only some files in the directory having issue with sys$qiow for accessing in my application.

Thank you.

[Hein van den Heuvel]

>> Accessing file using DIR/full  X.Dir

Unfortunate typo when it matters most? 

I though we were talkign about accessing a normal file, not a directory !?!

Is this a datafile called .DIR ?

>>  or editing the file having no issues.

>> Some other applications could access the file for backup.

I think we have our answer.

Everything can work with the file except the QIO program, which can access other files.

May I respectfully submit there is something broken in that program.

At this point my money would be on a FIB$W_DID contents being hosed/stuck/mismanaged.

>> But only some files in the directory having issue with sys$qiow for accessing in my application.

So what is special about those files? Name-length?

Odd characters?

Version number?

UpperCase / LOWERCASE ?

Admittedly this would all likely lead to 'file-not-found' but still...

Do a DIR/FILE on a file that does not work and see if you can back-translate it.

(xxxx,yy,z)

For example:

write sys$output F$fid("SYS$DISK:",f$file("login.com","FID"))

Or $ DUMP/HEAD/BLOCK=COUNT=1/ID=xxxx sys$disk

Show us some goodies! Actual directory listings, Actual error messages...

maybe the program trashes the return code... wouldn't be the first or the last.

Thank you.

Hein

[allin-in-one]

Hi,

I got output for failed and sucessful files deader dump. (i.e.  DUMP/HEAD/BLOCK=COUNT=1/ID=xxxx sys$disk)

I couldn't make any difference between them.

Thanks