Re: SD2IEC REL support

From: Jim Brain <brain_at_jbrain.com>
Date: Fri, 31 Jan 2020 19:16:55 -0600
Message-ID: <55bf2347-6a41-48c4-d3d1-c2b3f7c52b36_at_jbrain.com>
On 1/31/2020 6:47 PM, silverdr_at_wfmh.org.pl wrote:
>
>> On 2020-02-01, at 01:35, Jim Brain <brain_at_jbrain.com> wrote:
>>
>>>>> If you can create a simple test case that fails, I am happy to look into it.  Though my contributions to sd2iec are miniscule, I did implement some of the REL file support in there, and creating new files, adding records, etc. seemed to all work for me when I tested.  It may have suffered some regression, though, as it's been years.
>>>>>
>>>> Jim - thanks for stepping-in! I'll send you the PRG I found it failing with.
>>>>
>>> I did some debugging and it seems that the file gets actually created inside the directory. The program fails though, because it expects that after the file is created, the returned status is 50, RECORD NOT PRESENT as in other drives or IDE64 for example. SD2IEC returns 00, OK here, which – for whomever checks the status – means the file was not properly created.
>>>
>> OK, that is probably my fault, as I would never have guessed a successful open should return that error.
> Actually it's not simply opening the file. It is when creating new file (with content) by positioning record pointer beyond the end. This causes 50, RECORD NOT PRESENT and expands the file accordingly.
>
s/open/create

The initial

OPEN 1,8,2,"RELFIL,L,"+CHR$(<len>)//does not position the record, so I don't think it should trigger the 
error. I do send the error when you go past the current record number, 
but evidently, opening a file must be treated the same way, and the 
change I suggested will do so (though it's a bug, in my opinion). (It 
must be that the initial create does an internal position, which would 
indeed fail)

Jim


-- 
Jim Brain
brain_at_jbrain.com
www.jbrain.com
Received on 2020-05-30 00:40:50

Archive generated by hypermail 2.3.0.