OS/2, eCS & ArcaOS - Technical > Programming

REXX: RxStartSession, what is wrong with this call?

<< < (3/3)

Dariusz Piatkowski:
Hi Rich!

Ahh...Da Man himself (Rich is the author of oo, as well as the client/server portions that are utilized by oo)...alright sir.


--- Quote from: Rich Walsh on January 04, 2021, 08:04:29 pm ---
--- Quote from: Dariusz Piatkowski on January 04, 2021, 07:24:28 pm ---
--- Code: ---DEBUG ParseArgs => processing argument:0
DEBUG ParseObject => pArg:v:\photo
DEBUG ParseObject => pPath:
DEBUG ParseObject => DosQueryPathInfo API RC:15
invalid or malformed path

--- End code ---

--- End quote ---

I wouldn't claim to really understand what the above is saying, but shouldn't 'pPath:' be displaying "v:\photo"? If the path is null, rc=15 (ERROR_INVALID_DRIVE) would not be inappropriate.

--- End quote ---

You would be correct about that last statement, which is how I initially understood the code to work as well. However, upon further review I realized that this initial call to DosQueryPathInfo actually only checks that the path is a valid location. If so, there is a 2nd call to this API which then actually does the grunt work.

Specifically, here is the section of the code we are talking about:


--- Code: ---...
// expand partially-qualified names
    rc = DosQueryPathInfo(pArg, FIL_QUERYFULLNAME, pPath, CCHMAXPATH);

    printf("\nDEBUG ParseObject => DosQueryPathInfo API RC:%ld\n", rc);
   
    if (rc != 0)
        ERRBRK( "invalid or malformed path")

    // if we actually find something, then this is a file or directory;
    // otherwise, assume this is an abstract object's title
    if (DosQueryPathInfo( pPath, FIL_STANDARD, &fs3, sizeof(fs3)))
        *pType = typeTitle;
    else
        *pType = RWSI_OPATH;

    fRtn = TRUE;
...

--- End code ---

Since the 1st DosQueryPathInfo uses FIL_QUERYFULLNAME, that is a LEVEL_5 information block request, and per the CP book that "Level 5 returns the fully qualified ASCIIZ name of PathName in PathInfoBuf. PathName may contain global file-name characters". It is only at that point in time that pPath actually gets a value assigned to it, that being the fully qualified ASCIIZ path name.

Afterwards the 2nd DosQueryPathInfo call captures the LEVEL_3 info block into the 'fs3' variable.

So for some reason that 1st call fails here, but it only fails when executed from within my REXX script. If oo.exe is ran directly from CLI that works fine.

Here is a quick output of cflow showing where the oo.exe code halts:


--- Code: ---    1 {   0} +-main: int (int argc, char *argv[]), <oo.c 194>
    2 {   1}   +-RwsQueryVersion: <>
    3 {   1}   +-ErrMsg: void (char *msg, ULONG rc), <oo.c 1297>
    4 {   2}   | +-RwsGetRcString: <>
    5 {   2}   | +-sprintf: <>
    6 {   2}   | +-DosWrite: <>
    7 {   2}   | \-strlen: <>
    8 {   1}   +-printf: <>
    9 {   1}   +-ParseArgs: BOOL (int argc, char *argv[]), <oo.c 287>
   10 {   2}   | +-ParseExe: int (char *pArg), <oo.c 544>
   11 {   3}   | | +-strrchr: <>
   12 {   3}   | | +-strspn: <>
   13 {   3}   | | +-strchr: <>
   14 {   3}   | | \-UppercaseArg: BOOL (char *pArg), <oo.c 839>
   15 {   4}   | |   +-DosMapCase: <>
   16 {   4}   | |   \-strlen: <>
   17 {   2}   | +-printf: <>
   18 {   2}   | +-strspn: <>
   19 {   2}   | +-strchr: <>
   20 {   2}   | +-ERRBRK: <>
   21 {   2}   | +-ParseOption: int (char *pArg), <oo.c 591>
   22 {   3}   | | +-UppercaseArg: 14
   23 {   3}   | | +-strchr: <>
   24 {   3}   | | \-ErrMsg: 3
   25 {   2}   | +-ParseObject: BOOL (char *pArg, char *pPath, PULONG pType), <oo.c 640>
   26 {   3}   | | +-printf: <>
   27 {   3}   | | +-strchr: <>

DEBUG => This next statement is what catches the DosQueryPathInfo API call's RC=15

   28 {   3}   | | +-ERRBRK: <>

   29 {   3}   | | +-strcpy: <>
   30 {   3}   | | +-ParseHandle: BOOL (char *pArg, char *pPath, PULONG pType), <oo.c 736>
   31 {   4}   | | | +-strlen: <>
...

--- End code ---




Dariusz Piatkowski:
Hi Andreas,


--- Quote from: Andreas Schnellbacher on January 04, 2021, 08:02:01 pm ---rc = 15 is ERROR_INVALID_DRIVE. So DosQueryPathInfo failed to find the drive of v:\photo. Note that the toolkit docs have a few flaws. Is it a network drive? But strange that your first code block works. I guess we need to see the whole script for more hints on that.

When you're already in a REXX script, why don't you just use the following?

--- Code: ---rcx = SysSetObjectData( 'v:\photo', 'DEFAULTVIEW=XVIEW;')

--- End code ---

--- End quote ---

Yes, this is a network drive, basicaly a NetDrive connection to my NAS box. My REXX script checks that this location is still accessible every 15 mins. I do this because for some reason my NetDrive connection to this NAS box will go dead. I haven't figured out why it does this, it's only the NAS box itself, other NetDrive connections to Winx machines stay up. So for all I can tell there may be something inherent about the NAS box Samba server that just kills the connection NetDrive has started.

The problem is that numerous shadow objets in my WPS, which point to the NAS box, go dead and there really is no knowing about it unless and until you actually attempt to access that folder.

I tried the suggestion you provided as well. That was in fact my 1st approach. But for whatever reason I could not make that work. The call would execute but openning the shadow folder from WPS still produced an ICON view as opposed to the XVIEW one.

I've attached the whole script here (change the 'txt' to 'cmd' if you pull it into an IDE and want some sort of syntax highliting, etc.). The section where you see this comment is where my various attempts at making this work start:


--- Code: ---...
/* OK, now run the WPS settings utility */
...

--- End code ---

I also included the full clfow output for the oo.exe utility.

Andreas Schnellbacher:
The problem may be that drive V: doesn't support EAs. Then you can't apply a setup string to a file object.

Dariusz Piatkowski:

--- Quote from: Andreas Schnellbacher on January 04, 2021, 11:48:41 pm ---The problem may be that drive V: doesn't support EAs. Then you can't apply a setup string to a file object.

--- End quote ---

Yes, you are right, the NAS itself does not support EAs, so the NetDrive folder mapping itself does not either. However, the WPS shadow object does accept this setting because running oo.exe from CLI certainly does work. I have my one-off REXX cmd file doing precisely that, it just calls oo.exe multiple times, each time is specific to each folder shadow I have on my OS/2 Desktop.

Yeah, I am stumped by this, but again, not a heavy REXX or C/C++ developer here, so I'm sure there may be a few things I'm just overlooking (I hope  ;D).

Navigation

[0] Message Index

[*] Previous page

Go to full version