Odd behavior of OPEN_DIR

Anything QL Software or Programming Related.
Post Reply
Martin_Head
Aurora
Posts: 851
Joined: Tue Dec 17, 2013 1:17 pm

Odd behavior of OPEN_DIR

Post 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?


User avatar
tofro
Font of All Knowledge
Posts: 2699
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Odd behavior of OPEN_DIR

Post 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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
User avatar
RalfR
Aurora
Posts: 872
Joined: Fri Jun 15, 2018 8:58 pm

Re: Odd behavior of OPEN_DIR

Post 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.
Last edited by RalfR on Mon Mar 25, 2019 12:13 pm, edited 2 times in total.


4E75 7000
Martin_Head
Aurora
Posts: 851
Joined: Tue Dec 17, 2013 1:17 pm

Re: Odd behavior of OPEN_DIR

Post by Martin_Head »

OK thanks for that. So it's a 'feature' I can just ignore.


User avatar
mk79
QL Wafer Drive
Posts: 1349
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Odd behavior of OPEN_DIR

Post 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...


User avatar
janbredenbeek
Super Gold Card
Posts: 632
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: Odd behavior of OPEN_DIR

Post 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.


Martin_Head
Aurora
Posts: 851
Joined: Tue Dec 17, 2013 1:17 pm

Re: Odd behavior of OPEN_DIR

Post 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.


User avatar
tofro
Font of All Knowledge
Posts: 2699
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Odd behavior of OPEN_DIR

Post 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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Post Reply