Re: SD2IEC REL support

Using x64sc (vice 3,3) with a 1541 in real drive emulation mode, a 00
status is returned on opening a rel file.

10 open 15,8,15
20 open 1,8,1,"testfile,l,"+chr$(64)
30 input #15,e,e$,t,s
40 close 1
50 print e,e$,t,s
60 close 15

It seems that Jim's implementation of returning no error on opening
the file is okay.  Positioning to the first record will probably cause
a status 50 response given the rel file created is 0 blocks long and
not a splat file, but I'm too tired to verify that at the moment :)

-David

On Sat, Feb 1, 2020 at 1:19 AM Jim Brain <brain_at_jbrain.com> wrote:
>
> 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