Page 13 of 31
Re: QL / PASCAL
Posted: Sun Apr 04, 2021 4:37 pm
by NormanDunbar
Last one for today, I promise!
I've resolved the problem with renaming a file on the QL:
- If "oldfile" doesn't exist, Pascal barfs with runtime error 2 -- file not found.
- If newfile already exists, Pascal barfs with runtime error 5 -- file access error (sorry, the best I can do!)
- If oldfile there and newfile not, the file is renamed.
Unfortunately, I found another foible in SMSQ and deleteing a directory.
- If directory not empty, runtime error 5 occurs. File access error. (Sorry, best I can do!)
- If directory present, and empty of files, directory is deleted.
- If directory is not present, no errors occur! We expect a runtime error 3 Path not found.
So, I set up a couple of assembly language tests and IO_DELET doesn't care if the file is found or not, it doesn't return ERR_NF from the trap, it returns 0 instead. Hmmm.
I tried to open the non-existent directory, ram1_xxxxxx, as a directory before attempting to delete it, and it worked! Checking with the Channels thing, it had opened RAM1_ as a directory instead. It appears that SMSQ/QPC will do this if the given full filename is not a directory, it opens the next level up until it comes across something that is a directory? Or so it would seem.
This means that the QL version of rmdir, under Pascal, is different from the Linux version. Trying to delete a directory that's not there is expected to give error 3. Does anyone care?
Latest patch file attached below here.
Cheers,
Norm.
Re: QL / PASCAL
Posted: Sun Apr 04, 2021 5:46 pm
by pjw
I submitted FDEL (DELETE as a function) for inclusion in SMSQ/E v3.34 (I think). This returned error In Use if the file to be deleted was open (which was my main reason for doing it), but did not return Not Found if the file was missing, as the OS doesnt either.
I got an unofficial version of SMSQ/E in return. This version returned Not Found correctly. I think Marcel fixed it. However, when the official version was released, FDEL didnt work at all! It errored on everything. This was fixed by Wolfgang in a subsequent release, but then with my original version, ie no Not Found
I dont know where Marcel's version went, or what he had done to improve it. Test before delete, perhaps? or actually fixed the trap?
Personally, I dont find it mightily important. But of course, it would be better if it worked consistently - not least of all so as not to rub against anyone's OCDs
Re: QL / PASCAL
Posted: Sun Apr 04, 2021 6:48 pm
by NormanDunbar
I tried some assembly code running directly and not from Pascal. Traced through the delete and it never came back with ERR_NF.
Sounds like you have similar findings.
Cheers,
Norm.
Re: QL / PASCAL
Posted: Mon Apr 05, 2021 9:38 pm
by mk79
NormanDunbar wrote:So, I set up a couple of assembly language tests and IO_DELET doesn't care if the file is found or not, it doesn't return ERR_NF from the trap, it returns 0 instead. Hmmm.
Yes, that is by design. Not sure why.
I tried to open the non-existent directory, ram1_xxxxxx, as a directory before attempting to delete it, and it worked! Checking with the Channels thing, it had opened RAM1_ as a directory instead.It appears that SMSQ/QPC will do this if the given full filename is not a directory, it opens the next level up until it comes across something that is a directory? Or so it would seem.
That, too, is by design and many programs rely on it.
If you want to check if the filename exists use normal read-only open. You could then check the type and even error out if the thing you are deleting is not a directory in the case of rmdir
Cheers, Marcel
Re: QL / PASCAL
Posted: Mon Apr 05, 2021 9:41 pm
by mk79
NormanDunbar wrote:I tried some assembly code running directly and not from Pascal. Traced through the delete and it never came back with ERR_NF.
Code: Select all
dop_del
moveq #0,d2
moveq #0,d3
assert ddf.remove,-1
st d3
jsr ddf_drname(a4) ; search for name
bne.s dop_nfok ; ... not found is OK
[...]
dop_nfok
cmp.w #err.fdnf,d0 ; not found
bne.l dop_exit
dop_ok
moveq #0,d0
bra.l dop_exit
Not sure what I did or did not with FDEL, too long ago.
Cheers, Marcel
Re: QL / PASCAL
Posted: Mon Apr 05, 2021 10:21 pm
by pjw
Unarguably intentional. Perhaps it was done to avoid a program halting unnecessarily for an unimportant "error". Job already done. Why make a fuss?
Re: QL / PASCAL
Posted: Mon Apr 05, 2021 10:32 pm
by NormanDunbar
That explains why err_nf is not happening then. I'll try the other checks at some point. I wan't to add in default directory handling too. At least, I think I do!
Cheers,
Norm.
Re: QL / PASCAL
Posted: Tue Apr 06, 2021 12:40 pm
by mk79
NormanDunbar wrote:That explains why err_nf is not happening then. I'll try the other checks at some point. I wan't to add in default directory handling too. At least, I think I do!
If you do, please do it more like I do in the most current SMSQ/E, TK2: don't add a default directory if the filename starts with a valid drive identifier. I'm sick of files like "win1_system_win8_test" because my DATAD defaults to win1_system and win8_ wasn't available when the access has happened.
Cheers, Marcel
Re: QL / PASCAL
Posted: Tue Apr 06, 2021 4:41 pm
by NormanDunbar
Good point, thanks.
Re: QL / PASCAL
Posted: Tue Apr 06, 2021 5:46 pm
by martyn_hill
Hi Marcel!
mk79 wrote:...don't add a default directory if the filename starts with a valid drive identifier. I'm sick of files like "win1_system_win8_test" because my DATAD defaults to win1_system and win8_ wasn't available when the access has happened.
[Short, off-topic question] On this point of detecting whether a valid directory-device has already been specified, what is the most robust/elegant way to validate this, given the ever-growing list of possible devices that a user may have installed? I guess QPAC has a way to build it's list of available devices for the 'File' Thing...