Page 1 of 2

Odd behavour of the DIR command?

Posted: Tue Jul 24, 2018 3:50 pm
by Martin_Head
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?

Re: Odd behavour of the DIR command?

Posted: Tue Jul 24, 2018 5:30 pm
by tofro
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

Re: Odd behavour of the DIR command?

Posted: Tue Jul 24, 2018 6:30 pm
by RWAP
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...

Re: Odd behavour of the DIR command?

Posted: Wed Jul 25, 2018 10:15 am
by Martin_Head
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.
When I say operating system, I mean SMSQ/E. So TK2 is included.
RWAP wrote:Is Fifi marked as a directory (Ie was it made with MAKE_DIR) ?
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.
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.

Re: Odd behavour of the DIR command?

Posted: Wed Jul 25, 2018 7:56 pm
by Giorgio Garabello
I have just discovered that the DEV device has the exact same problem …

Giorgio

Re: Odd behavour of the DIR command?

Posted: Thu Jul 26, 2018 8:54 am
by Derek_Stewart
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.

Re: Odd behavour of the DIR command?

Posted: Thu Jul 26, 2018 9:45 am
by mk79
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

Re: Odd behavour of the DIR command?

Posted: Thu Jul 26, 2018 9:50 am
by Giorgio Garabello
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
and can not this problem be corrected?
Now that the network is also available for emulators, it is a very heavy limitation

Giorgio

Re: Odd behavour of the DIR command?

Posted: Thu Jul 26, 2018 10:43 am
by Martin_Head
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.

Re: Odd behavour of the DIR command?

Posted: Thu Jul 26, 2018 10:50 am
by pjw
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.