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?
Odd behavior of OPEN_DIR
Re: Odd behavior of OPEN_DIR
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:
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
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:
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.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.
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
Re: Odd behavior of OPEN_DIR
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.
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
-
- Aurora
- Posts: 862
- Joined: Tue Dec 17, 2013 1:17 pm
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: Odd behavior of OPEN_DIR
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...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.
- janbredenbeek
- Super Gold Card
- Posts: 637
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
- Contact:
Re: Odd behavior of OPEN_DIR
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.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?
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.
-
- Aurora
- Posts: 862
- Joined: Tue Dec 17, 2013 1:17 pm
Re: Odd behavior of OPEN_DIR
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.
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
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.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.
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