[Coco] DriveWire 4 seg fault under Linux Mint...

[Tormod Volden]

On Tue, Nov 11, 2014 at 4:32 PM, Aaron Wolfe  wrote:
> Ugh.. now I remember why I didn't take action on some of those.. i just
> really dont know what is the right thing to do.
>
> Standard DW behavior for reading beyond the end of the file is to succeed
> and return Os.  That's been the behavior since long before I became
> involved.   There is a setting I added to make this fail but I can't make
> it the default without breaking compatibility with previous versions.

Right, this is the "expand" parameter. To me it sounds most logical to
expand on write, but return an error on read. Because when reading,
the client should know the size of the file e.g. through a header,
however when building a file the client would need to expand it since
OP_NAMEDOBJ_CREATE makes an empty file.

Does anyone know any examples of clients that need to read "phantom" sectors?

However, I think I was mixing up this issue with another, which is
more clearly a bug: In some cases DriveWire4 does not return neither
data nor return code but just goes quiet. Very visible when using
Becker, since the client will hang forever (there is no timeout in the
HDB-DOS dwread routine for Becker, this is on my todo list).

One example is when DriveWire4 is not able to read from a file. So if
a file has been mounted but disappears, DriveWire4 just fails without
returning read error $F4 to the client. The log shows:
ERROR  DWProtocolHandler   dwproto-0-11        IOError in proto op:
Could not read from ... because it is a not a file.

I would have made the server keep the "mounted" files open so that
they cannot disappear, or check for their existence on every read.

>
> That's not as bad as the "files must be sized to sanely match sector size"
> issue.. DW only reads and writes sectors so what should it so with a file
> that doesn't align to sectors?  Refuse to serve up the incomplete sector,
> or pad it with zeros, make it read only, ?  The current model is all about
> the sectors, no mechanisms for communicating to the coco whether we have a
> full sector or not so it can't make the call on thst side as needed.

Padding any incomplete sector with zeroes is the most straight-forward
behaviour IMO. It won't change anything for existing full-sector use.
For writing there is no issue, because OP_WRITEX always needs a full
sector and the client can provide that.

>
> I don't want to break compatibility or create a scenario where files are
> getting trashed without the user wanting them to be.  What's the correct
> approach on these?

In what case could files be trashed?

Regards,
Tormod

>  On Nov 11, 2014 10:15 AM, "Tormod Volden" wrote:
>
>> On Tue, Nov 11, 2014 at 3:57 PM, Aaron Wolfe wrote:
>> > I suspect this could be fixed if I knew about it..
>> >
>> > I will try to find some time to release a version that supports your
>> > project better.  Can you send me a list of all known issues relative to
>> the
>> > current release?   There are so many bugs and unfinished bits in that
>> test
>> > version from the xfer directory.   We need to start from a saner place.
>>
>> Great! I discussed this project with you in April and gave you a list
>> of issues, but it might have grown a bit since then.
>>
>> 1. Ability to mount "images" that are not multiple of 256 bytes
>> 2. create named object request doesn't work
>> 3. reading beyond end of file does not return error code (silently fails)
>> 4. version 4.3.3p crashes on Ubuntu 12.04 (4.3.4d works great)
>> 5. survive without something mounted in drive0-4
>> 6. Some clear GUI indication if the server is in Turbo mode (although
>> I know Turbo is not supported yet)
>>
>> Regards,
>> Tormod