very newbie question: how to copy files

>Would this be wrong?

nope.

>
Better yet, would it be wrong to put the function CopyFile() into a header file in your compiler's include directory so all your programs may call CopyFile(old spot, new spot)?
<

it sounds fine to me.

>Or how about?

looks fine.

oh BTW: i forgot to close the files... i have corrected that error.

A "correct" way was my example. My example works fine with one slight modification. Again, the only reason it was "incorrect" is because apparently fputc is gimped and can't write EOF.

while( (c=fgetc(inputfile)) != EOF ) fputc( c, outfile );

This will work on binary or text files.

Quzah.

i never said it was incorrect, just slower. more memory efficient but slower.

>Would this be wrong? Better yet, would it be wrong to put the function CopyFile() into a header file in your compiler's include directory so all your programs may call CopyFile(old spot, new spot)?

Great idea. It is a perfect place for a function. In fact I had a CopyFile() function in one of my programs (actually it was c++).

Originally posted by no-one
i never said it was incorrect, just slower. more memory efficient but slower.

Yup. Salem said it was incorrect. My whole purpose in replying was to make one for the hell of it that didn't require the use of any varaibles. I wasn't trying to make a better wheel, just a different one.

Quzah.

much prettier than mine i must say.

as a stand alone program i wouldn't need all the specific file closeing
but as a function i need more specifics, like so is much better more like something i would use.

maybe this

Code:

#include <stdio.h>
#include <malloc.h>

#define CloseUp() if(fin)fclose(fin);if(fout)fclose(fout);if(buf)free(buf);

int main(void)
{
    FILE* fin,* fout;
    int filesize;
    char* buf = NULL;

    if(!(fin = fopen("C:\\filein.xxx","rb")))
    {
        printf("Unable To Open Input File\n");
        return -1;
    }
    if(!(fout = fopen("C:\\fileout.xxx","wb")))
    {
        printf("Unable To Open Output File\n");
        CloseUp();
        return -1;
    }

    fseek(fin,0,SEEK_END);
    if(!(filesize = ftell(fin)))
    {
        CloseUp();
        return 0;
    }
    
    fseek(fin,0,SEEK_SET);

    if(!(buf = (char*) malloc(filesize)))
    {
        printf("Out Of Memory\n");
        CloseUp();
        return -1;
    }

    if(fread(buf,1,filesize,fin) < filesize)
    {
        printf("File Read Error\n");
        CloseUp();
        return -1;
    }
    if(fwrite(buf,1,filesize,fout) < filesize)
    {
        printf("File Write Error\n");
        CloseUp();
        return -1;
    }
    CloseUp();
    return 0;
}

yes thats much better...

::edit:: still a little over complicated... in my opinion, im just waiting for Salem to smoke me with something better, which he undoubtably has.

> Better yet, would it be wrong to put the function CopyFile() into a header file in your
Yes - for two reasons
1. You don't put code into .h files, you put prototypes into .h files. The reason being, if you include the same file twice (in different source files say), you now have two copies of the code, with the same name, and one very confused linker.
2. Never put your own header files into the compiler's include directory - consider what would happen at upgrade time.

Your own include directory (and parallel lib directory) is the correct place for this.

> Again, the only reason it was "incorrect" is because apparently fputc is gimped and can't write EOF
There's nothing wrong with fputc - if you try your code, you'll see that the output is one char bigger than the input, and the last char in the file is (char)EOF.

EOF is a state - it's not read from a file, and its not written to a file.

Re: no-one's code.
Here are some points to ponder
1. malloc.h is not an ANSI header file, malloc is in stdlib.h
2. ftell returns a long, not an int - which may be different sizes. On some machines, your files would be clipped to a max size of 64K.
3. The whole malloc idea is bad - the scenario for large files is that most of the file lands in swap space, so not only do you read the file, you have to read it all again from swap.
4. if(!(filesize = ftell(fin))) this test fails should ftell ever return -1

> So if that isn't a good way to do it. What would the right way be Salem?
Prelude's fread/fwrite loop seems pretty good
For completeness, it should check ferror() on both input and output streams when the while loop exits.

Yes - for two reasons
1. You don't put code into .h files, you put prototypes into .h files. The reason being, if you include the same file twice (in different source files say), you now have two copies of the code, with the same name, and one very confused linker.

I overlooked that.

2. Never put your own header files into the compiler's include directory - consider what would happen at upgrade time.

Good point.

Thanks Salem.

folks, I have found the following:

-------------

Code:

#define BUFSIZE (4 * 1024)

...

int src_fd, dst_fd;
size_t bytes_read, bytes_written;
static char CopyBuf[BUFSIZE];
	
int final_ret = 0;
	
errno = 0;
	
/*--- cp -p aaa bbb ---*/
/*--- open source file ---*/
if ((src_fd = open(aaa_ptr, O_RDONLY)) == -1)
{
 final_ret++;
}
/*--- open destination file ---*/
if ((dst_fd = open(bbb_ptr, O_CREAT|O_TRUNC|O_WRONLY, (S_IREAD|S_IWRITE))) == -1)
{
 close(src_fd);
 final_ret++;
}
	
for 
(
bytes_read = -1, bytes_written = -1;
bytes_read == bytes_written && (bytes_read = read (src_fd, CopyBuf, BUFSIZE)) > 0;
bytes_written = write (dst_fd, CopyBuf, bytes_read)
)
{
/*--- void ---*/
}
	
close(src_fd);
close(dst_fd);

return final_ret;

-----------------------------------

comments?

> comments?

Yeah. Why are you bothering with low level functions such as 'open' and 'close' when you can just use 'fopen' etc? Shrug. Just curious.

Quzah.

>
Yes - for two reasons
1. You don't put code into .h files, you put prototypes into .h files. The reason being, if you include the same file twice (in different source files say), you now have two copies of the code, with the same name, and one very confused linker.
<

man, i am so ashamed, Sunlight im sorry! god it took him i can't remember how many post to knock that into my head!

>
2. Never put your own header files into the compiler's include directory - consider what would happen at upgrade time.

Your own include directory (and parallel lib directory) is the correct place for this.
<

once again not thinking!

>
Re: no-one's code.
Here are some points to ponder
<

i knew i missed something!

1. DOAH!! i told myself to use stdlib.h!

2. well... unfortunatly most of us wrongly a take 32 bit int for granted now... big mistake!

3. once again correct, but my intention was not for large file copying.

4. i should know better...

>Prelude's fread/fwrite loop seems pretty good

very nice, though slim on error checking quzah's is also not bad,
i was aimin for fastest possible small file copying.

>
Yeah. Why are you bothering with low level functions such as 'open' and 'close' when you can just use 'fopen' etc? Shrug. Just curious.
<

to avoid the sometimes large overhead of higher level functions, like fopen.

>comments?

i'll let Salem do it this time.

::edit::

Thanks Salem, honestly i appreciate it.

i don't think i would have te guts to post without you here,
i honestly appreciate you tearing my code up! i learn a lot from it. please do it any time you feel the urge.

::edit::

---
Yeah. Why are you bothering with low level functions such as 'open' and 'close' when you can just use 'fopen' etc? Shrug. Just curious.
---

to avoid the sometimes large overhead of higher level functions, like fopen.

---
exaclty my point