I'm genuinely scratching my head.. I have a a tool I've written that has subcommands to e.g. get a file from the network and put to the local disk.
I am opening the files "wb" to write them to disk, and I even tried to make sure I was writing at most 128 bytes at a time to disk, but files (such as ZIP files are coming across very mangled, and I'm at a loss...
Original ZIP:
https://drive.google.com/file/d/12isATP ... sp=sharing
ZIP after a copy to the host system and back again:
https://drive.google.com/file/d/1TqtQd0 ... sp=sharing
Code:
https://github.com/FujiNetWIFI/fujinet- ... /src/get.c
-Thom
stdio fles, opening with wb and rb, files getting mangled.
stdio fles, opening with wb and rb, files getting mangled.
You do not have the required permissions to view the files attached to this post.
Re: stdio fles, opening with wb and rb, files getting mangled.
Are you able to update your code to print to the screen whatever network_read puts into the buffer and then test with the transfer of a text file? This would help to ensure you're receiving the proper data before it's written to disk.
hited.zip is the same size as the original file but seems to have random data in it. To me it looks like the buffer is not being populated with the correct data at all rather than some kind of 'off-by-one' type problem.
hited.zip is the same size as the original file but seems to have random data in it. To me it looks like the buffer is not being populated with the correct data at all rather than some kind of 'off-by-one' type problem.
Re: stdio fles, opening with wb and rb, files getting mangled.
It's interesting, it looks like the contents of hited are the same (bar the padding) but (guessing here) the 64k blocks are in the wrong order.
If you try with a file < 64k I presume it works correctly?
If you try with a file < 64k I presume it works correctly?
Re: stdio fles, opening with wb and rb, files getting mangled.
I've just run this test:
Using zxcc and the file comes out in the correct order. Similarly when writing out 128 byte and 64 byte blocks. So file io seems to be working as expected.
It might be worth running a similar test on the Adam as sanity check.
Code: Select all
#include <stdio.h>
long buf[1024];
int main() {
long i;
FILE *fp = fopen("abc","wb");
for ( i = 0; i < 65536 * 10; i+= 1024 ) {
for ( long j = i; j < i + 1024; j++ ) {
buf[j - i] = j;
}
fwrite(buf, 4, 1024, fp);
}
fclose(fp);
}
It might be worth running a similar test on the Adam as sanity check.
Re: stdio fles, opening with wb and rb, files getting mangled.
Oh SHIT! Look at this!
-Thom
-Thom
You do not have the required permissions to view the files attached to this post.
Re: stdio fles, opening with wb and rb, files getting mangled.
Well, I narrowed it down to the 8mb CP/M image that is in use in the Adam community. Write a file larger than 64K? the extent wraps around, so probably an errant extent mask or block shift value in the DPB.
When I mentioned this to the guy who made the image, "Yeah, I know the problem, just haven't had the enthusiasm to fix it."
...he released a disk image, that Adam users are using...and it has this bug...and he knows about it....and he didn't even so much as put a warning label on it.
fucking hell.
So, it's not z88dk.
-Thom
When I mentioned this to the guy who made the image, "Yeah, I know the problem, just haven't had the enthusiasm to fix it."
...he released a disk image, that Adam users are using...and it has this bug...and he knows about it....and he didn't even so much as put a warning label on it.
fucking hell.
So, it's not z88dk.
-Thom