Author Topic: Fully qualified file specifications (of any valid file name argument)  (Read 8403 times)

xynixme

  • Guest
Is there an API which converts any valid file specification of an user to a fully qualified path. Like, assuming all are valid and the current working directory in C:\OS2:

FOO.BAR
\FOO.BAR
.\FOO.BAR
.\BITMAP\..\FOO.BAR
..\FOO.BAR
\\SERVER\OS2\FOO.BAR
C:FOO.BAR
C:\OS2\FOO.BAR

You can assume that the file FOO.BAR was created successfully earlier, by using fopen(). So if \\SERVER\OS2\FOO.BAR will never work, then you can skip that one. A Win*() API requires a fully qualified path, but an user could have entered anything that'll work with fopen(). So all I may know is "FOO.BAR".

Or do I have to check if there'a a "\". If so, "CHDIR" to it and query that current drive and directory?

Andreas Schnellbacher

  • Hero Member
  • *****
  • Posts: 827
  • Karma: +14/-0
    • View Profile
Re: Fully qualified file specifications (of any valid file name argument)
« Reply #1 on: September 02, 2019, 08:20:16 pm »
DosQueryPathInfo with FIL_QUERYFULLNAME. I don't know if it handles UNC names.

xynixme

  • Guest
Re: Fully qualified file specifications (of any valid file name argument)
« Reply #2 on: September 03, 2019, 03:04:53 am »
Thank you, that wasn't hard to apply.

Since failure is an option, I've taken care of UNCs by checking that the 2nd character is a ":". The API does understand specs like NUL, which expands to \DEV\NUL, so if an user with a network is lucky then e.g. \\SERVER\BMP\ECS24.BMP will be converted to O:\BMP\ECS24.BMP.

Andreas Schnellbacher

  • Hero Member
  • *****
  • Posts: 827
  • Karma: +14/-0
    • View Profile
Re: Fully qualified file specifications (of any valid file name argument)
« Reply #3 on: September 03, 2019, 09:38:08 pm »
Thanks for testing and reporting the behavior with UNC names.

xynixme

  • Guest
Re: Fully qualified file specifications (of any valid file name argument)
« Reply #4 on: September 04, 2019, 12:16:05 am »
Thanks for testing and reporting the behavior with UNC names.

I cannot test UNC names, but there should be 3 possibilities if an UNC is \\SERVER\2019\FILENAME.CMD:

1. API returns \\SERVER\2019\FILENAME.CMD, not being a fully qualified file name for an OS/2 object
2. API returns \\SERVER\2019\FILENAME.CMD, possibly a fully qualified file name for an OS/2 object
3. API returns P:\WAN\Accounting\2019\FILENAME.CMD, certainly a fully qualified file name for an OS/2 object
4. API's input is NUL, API returns \DEV\NUL

Since I cannot test (2), checking for a ":" as a second character is the-best-of-the-rest if the file has to be real. IOW, not a device pretending to be an existing file.

Doug Clark

  • Sr. Member
  • ****
  • Posts: 306
  • Karma: +7/-1
    • View Profile
Re: Fully qualified file specifications (of any valid file name argument)
« Reply #5 on: September 17, 2019, 12:13:12 am »
Since failure is an option, I've taken care of UNCs by checking that the 2nd character is a ":". The API does understand specs like NUL, which expands to \DEV\NUL, so if an user with a network is lucky then e.g. \\SERVER\BMP\ECS24.BMP will be converted to O:\BMP\ECS24.BMP.


Andre,

I am not sure I am completely understanding this thread, but I don't believe DosQueryPathInfo converts a UNC name to a drive letter type path/name.

The progarm PATHSTUFF in the attachment executes DosQueryPathInfo with FIL_QUERYFULLNAME to get the fully qualified path, and again with FIL_STANDARD to get the dates. In the attachment \\server1\ddrive is mapped to the drive letter q:   

If you are trying to distinguish between a device and a file for an argument passed to your program, perhaps DosQueryPathInfo would work. It appears to return error codes (invalid name, invalid access) when devices are passed to it as file names. Perhaps that would work.  If you are trying to distinguish between a directory and a file, I am at a loss.




xynixme

  • Guest
Re: Fully qualified file specifications (of any valid file name argument)
« Reply #6 on: September 17, 2019, 02:20:23 pm »
I am not sure I am completely understanding this thread, but I don't believe DosQueryPathInfo converts a UNC name to a drive letter type path/name.

The progarm PATHSTUFF in the attachment executes DosQueryPathInfo with FIL_QUERYFULLNAME to get the fully qualified path, and again with FIL_STANDARD to get the dates. In the attachment \\server1\ddrive is mapped to the drive letter q:

You did. Windows-versions of ported code introduced using their ShellExecuteA() API to (try to) open any valid file name argument. Apparently by using their DDE. The file, of the file name argument, does exist. AFAICare valid OS/2 arguments should include UNCs, if possible. Failure is an option. The original code doesn't check the return code, and there's no fatal error condition.

Interesting; thank you. I'll look at the sample later today. I would now use the Q: for the OS/2 shell, so if \\server1\ddrive is successfully converted then the second character after a conversion would become the ":" of "Q:". It does not matter if other APIs of functions do or don't understand the UNC, nor what ShellExecute() supports. If possible, I'll try to support UNCs too. It may be a problem that the path returned by PATHSTUFF isn't Q:\... though, without overengineering my solution.

Does the Rexx code below open the settings of the CONFIG.SYS of your sample?

Code: [Select]
/**/;CALL RxFuncAdd 'SysSetObjectData','RexxUtil','SysSetObjectData'

CALL SysSetObjectData '\\server1\cdrive\CONFIG.SYS','OPEN=SETTINGS'

EXIT
« Last Edit: September 17, 2019, 02:29:47 pm by AndrĂ© Heldoorn »

Doug Clark

  • Sr. Member
  • ****
  • Posts: 306
  • Karma: +7/-1
    • View Profile
Re: Fully qualified file specifications (of any valid file name argument)
« Reply #7 on: September 19, 2019, 10:44:21 pm »
Andre,

Executing the program
/**/
CALL RxFuncAdd 'SysSetObjectData','RexxUtil','SysSetObjectData'
CALL SysSetObjectData '\\server1\cdrive\CONFIG.SYS','OPEN=SETTINGS'
EXIT

opens a WPS object for \\server1\cdrive\config.sys - as shown in the first attachment.

Just for kicks, I created a WPS object for the Win-OS2 Notepad.exe application, and entered 
\\req1\cdrive\config.sys in the parameters.   req1 is the machine I was working on, i.e. the current machine.

The Win-OS2 Notepad opened the file \\req1\cdrive\config.sys - without converting the file name to a drive letter, even though \\req1\cdrive  = c:\
« Last Edit: September 19, 2019, 10:49:19 pm by Doug Clark »

xynixme

  • Guest
Re: Fully qualified file specifications (of any valid file name argument)
« Reply #8 on: September 22, 2019, 12:55:29 pm »
The Win-OS2 Notepad opened the file \\req1\cdrive\config.sys - without converting the file name to a drive letter, even though \\req1\cdrive  = c:\

Thank you, and interesting with good tests! The WPS requires a full file spec (or an object ID), and a.o. an UNC appears to qualify.

Now I'll "support" (not exclude, that is) UNCs if the second character of an expanded file name isn't a ":", even when it's perhaps more likely to type "C:\" instead of "\\server7\bootdrive".