Odd behavour of the DIR command?
-
- Aurora
- Posts: 854
- Joined: Tue Dec 17, 2013 1:17 pm
Odd behavour of the DIR command?
I have had a report of a problem with my IP Network driver. But the symptoms suggest to me that its an operating system problem.
If you set up a network of two stations NET 2, and NET 3
On NET 2 you run the file server FSERVE, and it has a directory WIN1_PRG_
On NET 3 you use NFS_USE shd,n2_win1_prg_
Now from NET 3 all of the following works as expected
DIR n2_win1_prg_
DIR shd1_
DIR n2_win1_prg_fifi_ ,where fifi_ is a subdirectory of win1_prg_
SAVE shd1_fifi_filename
VIEW shd1_fifi_xxx ,where xxx is a file that exists
OPEN_DIR#3,shd1_fifi_ : FOR x=0 to 128:PRINT INKEY$(#3) ; To read the file headers
However DIR shd1_fifi_ just returns the the drive details, and no files.
Now I know I have had problems with the DIR command and Networks before. But before I dig out a couple of real QL's and set up a Network to test this. Does anyone know if this is a known problem with the DIR command on a QL Network, rather than a problem in my driver?
If you set up a network of two stations NET 2, and NET 3
On NET 2 you run the file server FSERVE, and it has a directory WIN1_PRG_
On NET 3 you use NFS_USE shd,n2_win1_prg_
Now from NET 3 all of the following works as expected
DIR n2_win1_prg_
DIR shd1_
DIR n2_win1_prg_fifi_ ,where fifi_ is a subdirectory of win1_prg_
SAVE shd1_fifi_filename
VIEW shd1_fifi_xxx ,where xxx is a file that exists
OPEN_DIR#3,shd1_fifi_ : FOR x=0 to 128:PRINT INKEY$(#3) ; To read the file headers
However DIR shd1_fifi_ just returns the the drive details, and no files.
Now I know I have had problems with the DIR command and Networks before. But before I dig out a couple of real QL's and set up a Network to test this. Does anyone know if this is a known problem with the DIR command on a QL Network, rather than a problem in my driver?
Re: Odd behavour of the DIR command?
If OPEN_DIR, inkey$... works and shows the headers correctly, that is very probably not an operating system, but rather a TK2 problem.
DIR is intercepted by TK2 to extend for wildcards, while your "manual" method to read the directory is not.
Other than wildcard handling (and, maybe, IO.FSTRG calls rather than IO.FBYT), your driver should see very much the same calls for both commands.
Tobias
DIR is intercepted by TK2 to extend for wildcards, while your "manual" method to read the directory is not.
Other than wildcard handling (and, maybe, IO.FSTRG calls rather than IO.FBYT), your driver should see very much the same calls for both commands.
Tobias
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
-
- RWAP Master
- Posts: 2839
- Joined: Sun Nov 28, 2010 4:51 pm
- Location: Stone, United Kingdom
- Contact:
Re: Odd behavour of the DIR command?
Is Fifi marked as a directory (Ie was it made with MAKE_DIR) ?
That might explain the issue because TK2's network driver might ignore the directory flag and so thinks shd1_fifi_ is a file rather than a directory...
That might explain the issue because TK2's network driver might ignore the directory flag and so thinks shd1_fifi_ is a file rather than a directory...
Rich Mellor
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module - add a USB printer to your QL
Also Involved in:
Icephorm
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module - add a USB printer to your QL
Also Involved in:
Icephorm
-
- Aurora
- Posts: 854
- Joined: Tue Dec 17, 2013 1:17 pm
Re: Odd behavour of the DIR command?
When I say operating system, I mean SMSQ/E. So TK2 is included.tofro wrote:If OPEN_DIR, inkey$... works and shows the headers correctly, that is very probably not an operating system, but rather a TK2 problem.
Yes, As I said DIR n2_win1_prg_fifi_ works as expected, but DIR shd1_fifi_ Displays the Medium name and sector counts of the remote WIN1_ , but no files are listed.RWAP wrote:Is Fifi marked as a directory (Ie was it made with MAKE_DIR) ?
Which suggests to me that some directory has been opened on the remote WIN1_, but maybe DIR is looking for a file called fifi rather than a directory called fifi
Also, When you enter DIR shd1_fifi_, does the DIR command actually get "shd1_fifi_" , or has NFS_USE converted it to "n2_win1_prg_fifi_" before hand?
EDIT: Just dug out a couple of QL's. One a Trump card, one a Goldcard. and I can reproduce the same problem.
So It doesn't look like its a problem with my network driver, unless it's a pre-existing bug that got carried over in the conversion.
- Giorgio Garabello
- Gold Card
- Posts: 277
- Joined: Tue Jun 30, 2015 8:39 am
- Location: Turin, Italy
- Contact:
Re: Odd behavour of the DIR command?
I have just discovered that the DEV device has the exact same problem …
Giorgio
Giorgio
Quantum Technology
http://www.hunggartorino.it/ql/language/en/
http://www.hunggartorino.it/ql/language/en/
-
- Font of All Knowledge
- Posts: 3975
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Odd behavour of the DIR command?
Hi,
I used to have this problem in the 1990s, when I had a QXL networked with a QL with Supergold card running PBOX BBS system.
I used to refine the WIN device WIN1 as n1_WIN1_, using the NFS_USE command, to access the BBS files from the QXL.
There was always issues with regards to the when I tried to access the WIN1_PBOX_ which was actually n1_WIN1_PBOX_
I concluded there is a problem with the pattern matching on the NET server N1_WIN1_, the source could be the Network driver code for NFS_USE.
I assumed QL / SMSQ/E developers at that time did not use the Network, that any bugs in the network driver commands never got address. Though Minerva did try to resolve the poor network code.
I think I resolved the issue by using Phil Borman's SUB device or not using networked system for the QL.
I used to have this problem in the 1990s, when I had a QXL networked with a QL with Supergold card running PBOX BBS system.
I used to refine the WIN device WIN1 as n1_WIN1_, using the NFS_USE command, to access the BBS files from the QXL.
There was always issues with regards to the when I tried to access the WIN1_PBOX_ which was actually n1_WIN1_PBOX_
I concluded there is a problem with the pattern matching on the NET server N1_WIN1_, the source could be the Network driver code for NFS_USE.
I assumed QL / SMSQ/E developers at that time did not use the Network, that any bugs in the network driver commands never got address. Though Minerva did try to resolve the poor network code.
I think I resolved the issue by using Phil Borman's SUB device or not using networked system for the QL.
Regards,
Derek
Derek
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: Odd behavour of the DIR command?
The problem is that QL filenames always include the directory paths and the usual substitution devices like DEV only redirect the OPEN call, after that the channel is maintained by the other driver, so the result of DIR calls are not translated. This means that the DIR shd1_fifi here actually returns filenames as "prg_fifi", which the DIR then filters for names starting with "fifi" but they actually start with "prg", which in the end results in no files being listed.
Marcel
Marcel
- Giorgio Garabello
- Gold Card
- Posts: 277
- Joined: Tue Jun 30, 2015 8:39 am
- Location: Turin, Italy
- Contact:
Re: Odd behavour of the DIR command?
and can not this problem be corrected?mk79 wrote:The problem is that QL filenames always include the directory paths and the usual substitution devices like DEV only redirect the OPEN call, after that the channel is maintained by the other driver, so the result of DIR calls are not translated. This means that the DIR shd1_fifi here actually returns filenames as "prg_fifi", which the DIR then filters for names starting with "fifi" but they actually start with "prg", which in the end results in no files being listed.
Marcel
Now that the network is also available for emulators, it is a very heavy limitation
Giorgio
Quantum Technology
http://www.hunggartorino.it/ql/language/en/
http://www.hunggartorino.it/ql/language/en/
-
- Aurora
- Posts: 854
- Joined: Tue Dec 17, 2013 1:17 pm
Re: Odd behavour of the DIR command?
Yesterday I was tracing the problem through SMSQ/E. And the problem seems to be around wc_loop and wc_check in the SMSQ/E source sbext\ext\wclook_asm.
What seem to happen is that after the correct target directory has been opened and each entry is read. It is compared to the name supplied in the DIR command.
So if you used DIR n2_win1_prg_fifi_ it would compare
n2_win1_prg_fifi_xxxx where xxxx is the filename from a directory entry
n2_win1_prg_fifi_
which is fine, as the part up to the file name matches
But DIR shd1_fifi_ it would compare
shd1_prg_fifi_xxxx
shd1_fifi_
which fails as there is no match
DIR shd1_ compares
shd1_prg_xxxx
shd1_
although you would expect this to fail, it doesn't . I suspect it recognizes that there is nothing after the device name, and accepts it as a match
What I think needs to happen, Is that instead of using the supplied name, DIR should 'decode' any DEV_USE, or NFS_USE first, before trying the compare.
I realise that this could be tricky. How is DIR supposed to know when it has to decode the device name.
I wonder if DIR, instead of using the supplied name for the comparison, it used the file name from the channel definition block? Wouldn't this have already been decoded by the device driver when the directory is opened.
What seem to happen is that after the correct target directory has been opened and each entry is read. It is compared to the name supplied in the DIR command.
So if you used DIR n2_win1_prg_fifi_ it would compare
n2_win1_prg_fifi_xxxx where xxxx is the filename from a directory entry
n2_win1_prg_fifi_
which is fine, as the part up to the file name matches
But DIR shd1_fifi_ it would compare
shd1_prg_fifi_xxxx
shd1_fifi_
which fails as there is no match
DIR shd1_ compares
shd1_prg_xxxx
shd1_
although you would expect this to fail, it doesn't . I suspect it recognizes that there is nothing after the device name, and accepts it as a match
What I think needs to happen, Is that instead of using the supplied name, DIR should 'decode' any DEV_USE, or NFS_USE first, before trying the compare.
I realise that this could be tricky. How is DIR supposed to know when it has to decode the device name.
I wonder if DIR, instead of using the supplied name for the comparison, it used the file name from the channel definition block? Wouldn't this have already been decoded by the device driver when the directory is opened.
Re: Odd behavour of the DIR command?
This has been a longstanding issue. So when I discovered, on using the DEV device on SMSQ/E, that, for example, RENAME DEV8_abc, DEV8_xyz doest work (invalid name) I was not surprised. Im not sure its the same issue. Ive always just taken it to be a natural limitation of the system.
Per
dont be happy. worry
- ?
dont be happy. worry
- ?