Odd behavour of the DIR command?

Anything QL Software or Programming Related.
Martin_Head
Gold Card
Posts: 435
Joined: Tue Dec 17, 2013 1:17 pm

Odd behavour of the DIR command?

Postby Martin_Head » Tue Jul 24, 2018 3:50 pm

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?


User avatar
tofro
QL Wafer Drive
Posts: 1660
Joined: Sun Feb 13, 2011 10:53 pm
Location: SW Germany

Re: Odd behavour of the DIR command?

Postby tofro » Tue Jul 24, 2018 5:30 pm

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


ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
RWAP
RWAP Master
Posts: 2646
Joined: Sun Nov 28, 2010 4:51 pm
Location: Stone, United Kingdom
Contact:

Re: Odd behavour of the DIR command?

Postby RWAP » Tue Jul 24, 2018 6:30 pm

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


Martin_Head
Gold Card
Posts: 435
Joined: Tue Dec 17, 2013 1:17 pm

Re: Odd behavour of the DIR command?

Postby Martin_Head » Wed Jul 25, 2018 10:15 am

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.


User avatar
Giorgio Garabello
Trump Card
Posts: 242
Joined: Tue Jun 30, 2015 8:39 am
Location: Turin, ITaly
Contact:

Re: Odd behavour of the DIR command?

Postby Giorgio Garabello » Wed Jul 25, 2018 7:56 pm

I have just discovered that the DEV device has the exact same problem …

Giorgio


Derek_Stewart
QL Wafer Drive
Posts: 1489
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Odd behavour of the DIR command?

Postby Derek_Stewart » Thu Jul 26, 2018 8:54 am

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.


Regards,

Derek
User avatar
mk79
Gold Card
Posts: 398
Joined: Sun Feb 02, 2014 10:54 am

Re: Odd behavour of the DIR command?

Postby mk79 » Thu Jul 26, 2018 9:45 am

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


User avatar
Giorgio Garabello
Trump Card
Posts: 242
Joined: Tue Jun 30, 2015 8:39 am
Location: Turin, ITaly
Contact:

Re: Odd behavour of the DIR command?

Postby Giorgio Garabello » Thu Jul 26, 2018 9:50 am

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


Martin_Head
Gold Card
Posts: 435
Joined: Tue Dec 17, 2013 1:17 pm

Re: Odd behavour of the DIR command?

Postby Martin_Head » Thu Jul 26, 2018 10:43 am

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.


User avatar
pjw
Super Gold Card
Posts: 536
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: Odd behavour of the DIR command?

Postby pjw » Thu Jul 26, 2018 10:50 am

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
Be wary of large West-Coast corporations bearing gifts!
- Ancient Trojan proverb

Who is online

Users browsing this forum: No registered users and 5 guests