Page 2 of 2
Re: Odd behavour of the DIR command?
Posted: Thu Jul 26, 2018 11:03 am
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.
Re: Odd behavour of the DIR command?
Posted: Thu Jul 26, 2018 12:06 pm
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
Re: Odd behavour of the DIR command?
Posted: Fri Jul 27, 2018 10:27 am
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.
Re: Odd behavour of the DIR command?
Posted: Mon Jul 30, 2018 9:54 pm
by Giorgio Garabello
So using SUB sub extension instead DEV or NFS can solve the problem?
Giorgio
Re: Odd behavour of the DIR command?
Posted: Tue Aug 07, 2018 1:50 pm
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
Re: Odd behavour of the DIR command?
Posted: Wed Aug 08, 2018 11:13 am
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.
Re: Odd behavour of the DIR command?
Posted: Mon Aug 13, 2018 11:56 am
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.
Re: Odd behavour of the DIR command?
Posted: Tue Aug 14, 2018 7:07 pm
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