I'm getting separate path and file name strings from an ASL requester. If I Open() a file from the current directory, a file handle is returned and the rest of my program performs as expected.

But, if the chosen file is somewhere other than the current directory, first I get a Lock() from the path name and then feed that lock into CurrentDir() - both of which appear to work, then the subsequent call to Open() hangs...

What am I missing?

What Snoopium says?

To me it sounds the lock passed to CurrentDir() is not valid.

[ Edited by itix 31.12.2015 - 09:24 ]

Check for NULL.

Thank you for the quick reply.

Snoopium says...

Count: 1
Process Name: flux
Action: Open
Target Name: muidebug
Options: Read
Res: Fail

I have to admit ignorance with Snoopium as I've only used it a few times. I'm curious about the meaning of 'muidebug' as flux isn't a MUI program.

I'm going to look for some other ways to test that path name lock... In the mean time, I'm open to suggestions.

Edit: @Tcheko, you posted while I was entering the above. ;)

Lock() isn't returning NULL and from a cursory observation it seems to return a BPTR.

[ Edited by ausPPC 31.12.2015 - 18:42 ]

ausPPC,

There is another method that might be shorter and safer than moving with CurrentDir().

Concatenate the path and filename returned by the ASL requester with AddPart() dos function (beware of buffer overrun here, you have to provide the destination buffer...). This function takes care of all the nasty detail for path construction for you.

That way, you simply feed Open() with this concatenated string.

For debuging purpose, you can link with -ldebug:

Code:

Do not forgot to include the following proto:

Code:

And then, in your code:

Code:

This will output some stuff in the debug log. Do not forget the trailing '\n' that triggers the output in the debug log. If not present, nothing will show up in the debug log until something send this.

You can also add a define like this

Code:

And use D(kprintf("My conditional debug\n"));

Just #define DEBUG if you want the conditional debug.


About Snoopium:

It patches some DOS and Exec functions to track some system calls like Lock, Open, OpenLibrary and a bunch of others.

All processes that use the patched function will be tracked down in Snoopium. That's why you've seen this muidebug entry poping. There is a filter string gagdet at the bottom that you can make good use of. Insert #?yourprocessname#? here and every line that matches the pattern will show up in the output list.

Happy debugging.






[ Edited by Tcheko 31.12.2015 - 10:09 ]

Thank you again for your feedback. I think I tried giving Open() some full paths and it returned NULL - but I'll try again.

I just tried feeding that path name lock to Examine() and it recreated the path name in the file info block. Also, feeding it into UnLock() seemed to work.

It's been too long since I've done this kind of thing but I was a little surprised that the path name created by Examine() didn't include the root device - in this case, the same device as the current directory of the process.

We keep posting at the same time. ;)

This is a PPC assembly program that I'm debugging in my own debugger. But I'll bear those debug techniques in mind if I need them in a C program.

Doing asm only? You enjoy hurting yourself it seems. Haha. Good luck then. :)

Notice that a file that has an exclusive lock (ie already opened in exclusive mode for ex) will fail to be opened again if the lock hasn't been released correctly.

If you had a crash and a pending lock on the file, better reboot... (or try to get ride of the lock by calling the UnLock/Close whatever is holding the lock on the file if you still have the related BPTR. Nothing impossible but a reboot might be better in the end...).

Quote:

Are you sure that it isn't just a problem of using PPC assembly directly by not restoring/setting the appropriate registers in the end ?

The debugger lets me step through one instruction at a time so I was able to see that the specific call to Open() failed to return.

I don't know why my initial attempts to construct a full path and provide that as the input to Open() weren't always successful but I've since been using calls to AddPart() to create the input for Open() and so far it's worked as expected.