Page 1 of 1

Odd behavior of OPEN_DIR

Posted: Sun Mar 24, 2019 10:08 am
by Martin_Head
If I OPEN_DIR#3,xyz1_ in qemulator, where xyz1_ is a non existing device, or one that has a problem and returns a not found error. I get a 'Not found' error as expected.

However if I do the same in QPC2 (v4.05), I do not get any error message. I can even do things like PRINT INKEY$(#3) and some rubbish will be printed, but no errors.

Is this a bug in SMSQ/E, or is it intended?

Re: Odd behavior of OPEN_DIR

Posted: Sun Mar 24, 2019 10:40 am
by tofro
Martin,

it is a convention in SMSQ/E (or Level 2 device drivers?) that OPEN_DIR will never return an error (as long as there is some medium available, at least).

Quote from the reference guide:
Note also that most device drivers, when requested to open a directory will, if no such directory exists, open the next existing higher level directory. Most QL software expects this behaviour.
If a directory you want to open is not there, SMSQ/E will recursively remove underscore parts from the name, until it finds something it can actually open (if you are completely off, it will open the device's root directory). If not even the device is there, it will, I think, consider the device name a file name on the default directory and start the same mechanism there.

FNAME$ on such a channel returns the empty string, BTW.

If I walk through such a directory file, however, QPC2 returns file headers for files on ram1_ that never existed on my system....

Tobias

Re: Odd behavior of OPEN_DIR

Posted: Sun Mar 24, 2019 12:50 pm
by RalfR
That's what I always said and have done in S_Edit: Simply set the SV_DDLST variable to zero (save it and set it later), so that TK2 can't check for any of its default directories so you use the one, you have typed.

It is simply sometimes annoying with the so called "default directories".

If one can't find "win1_test_myprog_asm" who want the system to search for "flp1_win1_test_myprog_asm" if "flp1_" is the DATA or PROG default? That's really totally stupid.

Re: Odd behavior of OPEN_DIR

Posted: Mon Mar 25, 2019 9:44 am
by Martin_Head
OK thanks for that. So it's a 'feature' I can just ignore.

Re: Odd behavior of OPEN_DIR

Posted: Mon Mar 25, 2019 12:41 pm
by mk79
Martin_Head wrote:If I OPEN_DIR#3,xyz1_ in qemulator, where xyz1_ is a non existing device, or one that has a problem and returns a not found error. I get a 'Not found' error as expected.
Tobias said pretty much everything, but I guess you didn't have TK2 loaded or DATA_USE set. Otherwise you'd see that QemuLator will also not return "not found", because that's the QL way, like it or not...

Re: Odd behavior of OPEN_DIR

Posted: Mon Mar 25, 2019 11:08 pm
by janbredenbeek
Martin_Head wrote:If I OPEN_DIR#3,xyz1_ in qemulator, where xyz1_ is a non existing device, or one that has a problem and returns a not found error. I get a 'Not found' error as expected.
However if I do the same in QPC2 (v4.05), I do not get any error message. I can even do things like PRINT INKEY$(#3) and some rubbish will be printed, but no errors.
Is this a bug in SMSQ/E, or is it intended?
There used to be a bug in Qemulator when opening a directory - when you opened win1_xyz as directory (when win1_ is a valid device but there is no file xyz) it returned 'not found', where in fact it should have returned OK (because you opened a directory, not a file). This caused default directory aware applications (like newer versions of QED) to retry the open with the default directory prepended to the original name so you would get something like win1_win1_xyz as file name, but OPEN_DIR would still return 'not found' even if the default device was valid.
This behaviour has been corrected in the latest version (3.2.1). Of course this has the side effect that opening a file on a non-existent device will also be retried with the default directory prepended - that's just the way default directories work.

Jan.

Re: Odd behavior of OPEN_DIR

Posted: Wed Mar 27, 2019 10:10 am
by Martin_Head
What it was, Is that I was using OPEN_DIR to trace through the open routine of a directory device driver I am playing with. But the open routine was failing and returning a 'not found' error, because it was failing to correctly recognize the storage media when it tried to access it for the first time.

As I knew the driver was reporting an an error back to the operating system, I was bit surprised that the error was not displayed.

Re: Odd behavior of OPEN_DIR

Posted: Wed Mar 27, 2019 11:44 am
by tofro
Martin_Head wrote:What it was, Is that I was using OPEN_DIR to trace through the open routine of a directory device driver I am playing with. But the open routine was failing and returning a 'not found' error, because it was failing to correctly recognize the storage media when it tried to access it for the first time.
As you see from the above excerpt of the manual, a directory device driver is not really expected to ever return "not found" for a directory.

It may return physical media errors ("bad or changed medium") and the like, but never "not found" - it should return the opened root directory (or the next best "upper layer" directory) when what you're trying to open is not there.

Tobias