Problem with fread

Here is an example of what your code should look like:

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

int main(int argc, char *argv[])

{

FILE *fin = NULL, *fout = NULL;

char *ptr = NULL;

size_t len = 65536;

int result = -1;

if(!(fin = fopen(argv[1], "rb")))

{

printf("The input file: %s could not be opened\n", argv[1]);

return -1;

}

if((fout = fopen(argv[2], "rb")))

{

printf("The output file %s already exist\n", argv[2]);

fclose(fin);

return -1;

}

if (!(fout = fopen(argv[2],"wb")))

{

printf("Cannot write output file %s\n", argv[2]);

fclose(fin);

return -1;

}

if (!(ptr = malloc(len)))

{

printf("Canot allocate %zd bytes\n", len);

fclose(fin);

fclose(fout);

return -1;

}

while(1)

{

int amountRead = fread(ptr, sizeof(char), len, fin);

if(amountRead)

{

int amountWritten = fwrite(ptr, sizeof(char), amountRead, fout);

if(amountWritten != amountRead)

{

printf("Cannot write file\n");

break;

}

}

if(amountRead < len)

{

result = 0;

break;

}

}

fclose(fin);

fclose(fout);

free(ptr);

return result;

}

"There is no reason to ever issue a single I/O request of 2 GB. There is no reason to issue a single I/O request of more than 64k."

I don't know, maybe here's one.

I have a 24 GB file that I need to transfer to Windows via USB drive.

I can't write > 4 GB to FAT32, I can't write at all to NTFS, and Windows won't read HFS+.

All I can think of is to split the file into smaller pieces and then put them back together under Windows with something like "copy /b Archive.zip_* Archive.zip". Is there an easy alternative?

It's only 12 parts of 2 GB each; a few more (378479) if they were only 64 kB each--I think I'll fread as much as I can.

Somewhat more related to this thread: I tried 4 GB which seems to run without error under Snow Leopard but the last partial read always comes out to 4 GB, so I am sticking with 2 GB chunks (2^31 - 1 to be exact) which gets the length of the last part correct.

schecae1 wrote:

I have a 24 GB file that I need to transfer to Windows via USB drive.

I can't write > 4 GB to FAT32, I can't write at all to NTFS, and Windows won't read HFS+.

All I can think of is to split the file into smaller pieces and then put them back together under Windows with something like "copy /b Archive.zip_* Archive.zip". Is there an easy alternative?

Use the "split" command to split your file into chunks. Then copy each chunk. That "copy" command on Windows should suffice to restore all the parts into one big whole.

This thread is about a really low-level, ancient piece of code, being used horribly wrong. Unless you are really talking about programming, such a question would be better suited to the MacOS X Technologies forum. In al cases, it is best to start your own question instead of piggy-backing onto someone else's question. Dredging up an old thread like this is a sure way to get your question ignored.

stéphane69 wrote:

When i got some news about this bug i'll post it.

Don't hold your breath waiting. That's just boilerplate text that everyone gets when they file a bug. When and if any changes ever get made, they will be made against the original bug report, not your duplicate. You will get no further news from Apple about this.

As I have tried to explain, you shouldn't ever allocete a buffer anywhere close to 2 GB. In order for such a program to run, your machine would have to have 2 GB of free RAM. You are asking someone to swap out half their RAM just to make one function call.

stéphane69 wrote:

Again, please talk about what you understand and know.

Learn programming.

return value of fread is not unsigned short (your example above) or int and there is reason for that.

reasons that obviously you do not know.

Again learn programming.

And if you want to continue barking like you do on this problem its your choice, its just wasting time and trolling.

At this point, it is mostly morbid fascination 🙂

I'm curious why you keep saying "unsigned short". Is that because I used a buffer size of 65536? It has nothing to do with unsigned short. That is just an optimal buffer size. Once you get any larger than that, the return on speed from larger sizes drops very quickly. Furthermore, in a modern application, your process will lock up if you try a buffer size of 1 GB. If you read in smaller chunks, you can keep processing events and updating progress bars.

For example, I took my demo program and changed the buffer size. I used it to copy a 1.6 GB file. Here are the results:

64K buffer

$ time /tmp/a.out "in.dmg" out.bin

/tmp/a.out "in.dmg" out.bin 0.19s user 5.18s system 6% cpu 1:17.31 total

128K buffer

$ time /tmp/a.out "in.dmg" out.bin2

/tmp/a.out "in.dmg" out.bin2 0.18s user 5.19s system 18% cpu 28.864 total

256K buffer

$ time /tmp/a.out "in.dmg" out.bin3

/tmp/a.out "in.dmg" out.bin3 0.17s user 5.14s system 17% cpu 30.090 total

1 GB buffer

$ time /tmp/a.out "in.dmg" out.bin4

/tmp/a.out "in.dmg" out.bin4 0.16s user 5.64s system 18% cpu 31.113 total

In this example, 128K is actually what I should have used. Using a buffer any larger than that actually makes the program run more slowly.

Look, I realize you are a new programmer so I'm trying to help here. Having a belligerant attitude like that will be a Career Limiting Move. I make a point not to explain in Apple Support Communities the kind of software I write professionally. I prefer to engage people and explain things in a way that they can understand instead of making claims of X, Y, and Z that could never be substantiated anyway.

I would like to help you become a better programmer if you will meet me halfway. If not, then that's your loss.

So you posted made-up code rather than what is actually being used.

How do you expect do get help doing that?

etresoft, stop wasting your time.