AmigaDOS Question
14 messages in this thread
Hi there…
Is there any way to find out how much data has been written to disk when
the DISK_FULL error occurs? I'm using 1.3 and I was thinking that the
packet ACTION_READ_RETURN/WRITE_RETURN might tell me the actual number, not
just -1.
Thanks a bunch…
David
David,
Just glancing at my DOS manual, I didn't find anything on the packets you
mentioned. However, you could keep a running total of the number of bytes
actually written each time you write to the file (as returned by the Write
function or packet).
Regards,
Shraddhan – via Whap! from Hertfordshire in the UK
Shraddhan…
The packet ACTION_READ_RETURN is 1001, I found it in the 1.3 Includes &
AutoDocs. So if I muddle around with it I might come up with something..HA
<smile>. I thought about keeping a running total but the WRITE DOS call
will still return -1 when the disk is full. So if I was to write a 900k
file to disk, I wouldn't be able to know exactly how much was written and
how much still needs to be finished. But I might try and approximate the
size of the WRITE before hand by block size of the file versus the number
of blocks remaining on disk. That way I'll still have some room left over
just incase <smile>.
But that ACTION_READ_RETURN still makes me wonder…
Thanks…
David
David,
I found the definition of ACTION_READ_RETURN, but no clue as to its
purpose.
I was just wondering – when Write (or ACTION_WRITE) fails due to a disk
full condition, does it actually write as many bytes as possible first, or
does it realise that there is no room for the block of data, and not write
any bytes at all? The latter would seem to be more convenient for the
programmer calling the routine, and perhaps this is what actually happens.
If so, you're in luck. Unfortunately, I don't have this information.
If you try writing a 900k block to disk, does anything get written at all?
Regards,
Shraddhan – via Whap! from Hertfordshire in the UK
ACTION_READ_RETURN and ACTION_WRITE_RETURN are used by the handler to
basically talk to itself 🙂 Seriously, a handler often creates a packet
to be returned to it when an async. operation is complete. (A packet can
be considered an overgrown message). For instance, when the con-handler
reads characters from the console.device, it sets up the packet (message)
that will be returned to it with the new characters. The packet type set
is ACTION_READ_RETURN. The con-handler has only one message port; all
messages come through that. The ACTION_READ_RETURN lets the con-handler
know what the incoming message is, so it processes it properly. When you
can have more than one message outstanding, you need to develop a means of
telling them apart when they come back.
andy
Andy,
I gather from your description that using a packet ACTION_READ_RETURN is
kind of an alternative to the handler checking to see if it recognises the
address of the packets it receives to see if the packet was one it created
(and sent) in the first place.
Thanks for the info.
Regards,
Shraddhan – via Whap! from Hertfordshire in the UK
That is a reasonable assumption. When a handler has tons of packets going
each way, this is a quick way to separate out processing.
Basically, yes. The packets become 'self-identifying', so the handler
doesn't have to keep a table of addresses somewhere. Its a useful
technique in a message passing system like the Amiga OS.
andy
Shraddhan…
Unfortunately when WRITE returns a DISK_FULL error its after it has already
written it, no pre-planning involved <sigh>. Even the internal pointers
are cleared out, so I can't even tell WHERE in the file it stopped. I'll
find something out though <smile>.
Thanks… David
David,
I'm stumped. Sounds to me there's a design error in the WRITE routine.
Good luck…
Regards,
Shraddhan – via Whap! from Hertfordshire in the UK
You also have to remember that there are tons of handlers out there and
each one handles the situation differently. A handler can abort
immediately if it determines that there is not enough disk space at all.
My best advice would be to break up the operation into smaller chunks.
Actually, is there a different way to approach the problem that you are
trying to solve? What is the base issue that you are trying to address?
In short, you can't find out. The handler does all the work to back out
the process of the write before returning the packet to you.