Odd behavour of the DIR command?

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

Re: Odd behavour of the DIR command?

Post by Martin_Head »

I'm pretty sure that DIR, STAT, RENANE, COPY, and all the W variants, all use the wclook_asm code. So although I have been talking about DIR, I would expect similar problems with all those commands.


User avatar
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?

Post by mk79 »

Giorgio Garabello wrote:and can not this problem be corrected?
Sure, the SUB device shows that it can be done. But it means a pretty big rewrite.
Martin_Head wrote: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.
Then all other code working with directories like the QPAC2 Files menu is still broken. If any effort is spent on this I think it would best be solved on the device driver level.

Marcel


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

Re: Odd behavour of the DIR command?

Post by Martin_Head »

Marcel wrote:
Martin_Head wrote: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.
Then all other code working with directories like the QPAC2 Files menu is still broken. If any effort is spent on this I think it would best be solved on the device driver level.

Marcel
I don't see how the device driver can really solve this problem. Unless you do away with NFS_USE and DEV_USE entirely.

The only way that immediately comes to mind, is that the device driver would have to remember (in the channel definition block?) that the directory channel was opened using a NFS_USE substitution. Then whenever directory entries are read (and written?), actively patch the directory paths in the headers of the data it's reading, to suit what the DIR, or COPY or whatever, command is expecting.
This could be an awful mess, as the I/O routine in the driver has no idea if the directory was opened for a DIR, or someone is genuinely trying to read the directory.

Unless you have another solution that I have not thought of.

I did suggest a an idea to Giorgo of a work around for the problem in my Network driver, at the SBASIC level.

Code: Select all

DEFine Procedure XDIR (a$)
 LOCal b$
 b$=NFS_USE$(a$(4))&a$(6 TO )
 DIR b$
END DEFine XDIR
This procedure decodes the NFS_USE name back to a real name.
When you want to do a sub directory of a NFS_USE device e.g. DIR SHD1_FIFI_ do XDIR "SHD1_FIFI_" instead.

I do appreciate the potential problems of trying to change the way the the wild card comparisons work in SMSQ/E and how it can have detrimental effects in other places.


User avatar
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?

Post by Giorgio Garabello »

So using SUB sub extension instead DEV or NFS can solve the problem?

Giorgio


User avatar
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?

Post by mk79 »

Martin_Head wrote:I don't see how the device driver can really solve this problem. Unless you do away with NFS_USE and DEV_USE entirely.

The only way that immediately comes to mind, is that the device driver would have to remember (in the channel definition block?) that the directory channel was opened using a NFS_USE substitution. Then whenever directory entries are read (and written?), actively patch the directory paths in the headers of the data it's reading, to suit what the DIR, or COPY or whatever, command is expecting.
This could be an awful mess, as the I/O routine in the driver has no idea if the directory was opened for a DIR, or someone is genuinely trying to read the directory.
Missed this post, sorry. Not the target device driver must remember that it was opened differently. The N_ or DEV_ device must translate the directory I/O calls and strip the leading filename parts. This is what the SUB device is doing and technically it looks like the cleanest solution.

Marcel


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

Re: Odd behavour of the DIR command?

Post by Martin_Head »

Is this the SUB device from Dilwyn Jones's web site in drivers.zip from the toolkits section?

Is the source code available so I can see how it's done.


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

Re: Odd behavour of the DIR command?

Post by Martin_Head »

I have disassembled the SUB device driver. And what it does, is that the I/O routine traps any IO.FSTRG calls after they have been done.
It also patches FS.RENAME calls

In the IO.FSTRG calls, if the file type is a directory, and the number of bytes fetched is exactly 64 (a file header), then the file name in the header is patched if needed. As Marcel says.

However there are at least a couple of problems I can see.
1.If the file header is read with IO.FBYTE, it will not be patched. - Probably not a great problem.

2.If an application reads a file header, then writes the complete header back out, after say changing the backup date. Then the SUB device would write the header back with the patched file name. - Possibly causing all sorts of problems for the storage device.

I am thinking about trying to implement something along these lines in my IP Network driver.
For problem 2, I would either have to implement some sort of write protect system, or de-patch the file name before saving the header.

Can anyone see any other possible problems that I would need to consider before continuing.


User avatar
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?

Post by mk79 »

Martin_Head wrote:I have disassembled the SUB device driver. And what it does, is that the I/O routine traps any IO.FSTRG calls after they have been done.
It also patches FS.RENAME calls
Yeah, sorry, I've already done this, too. If anybody is curious, my file is attached.
However there are at least a couple of problems I can see.
1.If the file header is read with IO.FBYTE, it will not be patched. - Probably not a great problem.
I don't think so either.
2.If an application reads a file header, then writes the complete header back out, after say changing the backup date. Then the SUB device would write the header back with the patched file name. - Possibly causing all sorts of problems for the storage device.
You cannot change the filename by writing the header, this part is always ignored by the driver.
Can anyone see any other possible problems that I would need to consider before continuing.
I think this approach is much cleaner than the status-quo.

Cheers, Marcel
Attachments
sub_rext.zip
(4.48 KiB) Downloaded 127 times


Post Reply