Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

C Programming Language

Looking for a C system call to copy files


Hi,

Is there a UNIX C system command that will let me copy a file?
I am looking for something similar to "cp" that can be called within a
C program.
I know of the "link" system call but this command will set a the
second file as a link to the first file rather than an independent
copy of the first file.
(Windows has the CopyFile command but I didn't find anything that
would work under UNIX)

I am also looking for C commands to move files. Is the C system call
"rename" equivalent to Window's specific MoveFileEx function?

Thanks,
Avner Moshkovitz
Research Analyst
Email: amosh@mda.ca

Avi wrote:
> Hi,

> Is there a UNIX C system command that will let me copy a file?
> I am looking for something similar to "cp" that can be called within a
> C program.
> I know of the "link" system call but this command will set a the
> second file as a link to the first file rather than an independent
> copy of the first file.
> (Windows has the CopyFile command but I didn't find anything that
> would work under UNIX)

> I am also looking for C commands to move files. Is the C system call
> "rename" equivalent to Window's specific MoveFileEx function?

comp.unix.programmer would be a better place for these questions.  The
only standard C way would be to use the system() function to invoke the
appropriate commands.

--
Ian Collins.

Avi said:

> Hi,

> Is there a UNIX C system command that will let me copy a file?
> I am looking for something similar to "cp" that can be called within a
> C program.

#include <stdio.h>

#define COPYFILE_OK             0
#define COPYFILE_READ_ERROR     1
#define COPYFILE_WRITE_ERROR    2
#define COPYFILE_OUTCLOSE_ERROR 4
#define COPYFILE_OUTOPEN_ERROR  8
#define COPYFILE_INCLOSE_ERROR  16
#define COPYFILE_INOPEN_ERROR   32

int copyoneunixfiletoanother(const char *fntarget, const char *fnsource)
{
  int rc = COPYFILE_OK;
  FILE *fpin = fopen(fnsource, "rb");
  if(fpin != NULL)
  {
    FILE *fpout = fopen(fntarget, "wb");
    if(fpout != NULL)
    {
      int ch = 0;
      while((ch = getc(fpin)) != EOF)
      {
        putc(ch, fpout);
      }
      if(ferror(fpin))
      {
        rc |= COPYFILE_READ_ERROR;
      }
      if(ferror(fpout))
      {
        rc |= COPYFILE_WRITE_ERROR;
      }
      if(fclose(fpout) != 0)
      {
        rc |= COPYFILE_OUTCLOSE_ERROR;
      }
    }
    else
    {
      rc |= COPYFILE_OUTOPEN_ERROR;
    }
    if(fclose(fpin) != 0)
    {
      rc |= COPYFILE_INCLOSE_ERROR;
  }
  else
  {
    rc |= COPYFILE_INOPEN_ERROR;
  }
  return rc;

}

<snip>

> I am also looking for C commands to move files. Is the C system call
> "rename" equivalent to Window's specific MoveFileEx function?

The standard C library function, rename(), changes the name of a file.
If your implementation considers a file's path to be part of its name,
then it will presumably allow you to move files using rename().

> Thanks,
> Avner Moshkovitz
> Research Analyst
> Email: amosh@mda.ca

Consider extending your researches to encompass "The C Programming
Language", 2nd edition, by Brian W Kernighan and Dennis M Ritchie,
which covers the above topics on pp 16-17, 162, and 242.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Avi wrote:

> Is there a UNIX C system command that will let me copy a file? I
> am looking for something similar to "cp" that can be called within
> a C program.  I know of the "link" system call but this command
> will set a the second file as a link to the first file rather than
> an independent copy of the first file.
> (Windows has the CopyFile command but I didn't find anything that
> would work under UNIX)

> I am also looking for C commands to move files. Is the C system
> call "rename" equivalent to Window's specific MoveFileEx function?

So write them.  They are very simple.  For example, to copy a file:

  /* first open the files in the calling function */
  void fcopy(FILE *fromf, FILE *destf) {
     int ch;

     while (EOF != (ch = getc(fromf))) putc(ch, destf);
  } /* untested */
  /* now close both files */

You may want to add some error checking on the putc operation, and
the necessary #includes.

--
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
 <http://kadaitcha.cx/vista/dogsbreakfast/index.html>
                        cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

On Tue, 29 May 2007 00:05:49 +0000, Richard Heathfield wrote:
>Avi said:
>> Is there a UNIX C system command that will let me copy a file?
>> I am looking for something similar to "cp" that can be called within a
>> C program.

IIRC, cp can be called from within a C program.

Here obviously the closing brace is missing. Moreover, the return
value of fclose() should never be considered when the file was opened
only for reading.

rename() presumably works when source and destination are on the same
file system. A move_file function should first try to use rename() and
in case of failure copy the file.

--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

Roland Pibinger said:

> On Tue, 29 May 2007 00:05:49 +0000, Richard Heathfield wrote:

<snip>

>>      rc |= COPYFILE_INCLOSE_ERROR;

> Here obviously the closing brace is missing.

Whoops.

> Moreover, the return
> value of fclose() should never be considered when the file was opened
> only for reading.

I can see why you might choose to omit the check, but I think "never" is
overstating your case.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Why did you chose not to check the return value of putc()?

Bjrn

[snip]

--
Looking for an embeddable web server?
http://www.metasystems.no/products/highlander/index.html

B. Augestad said:

<snip>

> Why did you chose not to check the return value of putc()?

ferror(fpout) is tested later in the code.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

Richard Heathfield wrote:
> B. Augestad said:

> <snip>
>> Why did you chose not to check the return value of putc()?

> ferror(fpout) is tested later in the code.

I saw that, but what if the call to putc() fails on the first byte out
of a couple of gigabytes? The code will keep calling putc() millions of
times. Either that or one risks partial copies.

Bjrn

B. Augestad said:

> Richard Heathfield wrote:
>> B. Augestad said:

>> <snip>
>>> Why did you chose not to check the return value of putc()?

>> ferror(fpout) is tested later in the code.

> I saw that, but what if the call to putc() fails on the first byte out
> of a couple of gigabytes?

Fair point. Feel free to adjust the code accordingly if you wish.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

On Tue, 29 May 2007 20:47:00 +0200, "B. Augestad" wrote:
>Richard Heathfield wrote:
>> B. Augestad said:

>> <snip>
>>> Why did you chose not to check the return value of putc()?

>> ferror(fpout) is tested later in the code.

>I saw that, but what if the call to putc() fails on the first byte out
>of a couple of gigabytes? The code will keep calling putc() millions of
>times. Either that or one risks partial copies.

The implementation must be fast for the usual successful case, not the
rare error case. The code assumes that putc() and getc() are macros
(i.e. they are nor called). Partial copies are avoided by using a
temporal file(name) as destination which is renamed after successful
completion of the copy operation.

--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

Roland Pibinger wrote:
> On Tue, 29 May 2007 20:47:00 +0200, "B. Augestad" wrote:
>> Richard Heathfield wrote:
>>> B. Augestad said:

>>> <snip>
>>>> Why did you chose not to check the return value of putc()?
>>> ferror(fpout) is tested later in the code.
>> I saw that, but what if the call to putc() fails on the first byte out
>> of a couple of gigabytes? The code will keep calling putc() millions of
>> times. Either that or one risks partial copies.

> The implementation must be fast for the usual successful case, not the
> rare error case. The code assumes that putc() and getc() are macros
> (i.e. they are nor called).

Are you advocating that we drop error checking because it slows down the
'usual successful case'?

> Partial copies are avoided by using a
> temporal file(name) as destination which is renamed after successful
> completion of the copy operation.

How does that help? If the code is used to copy 1GB and putc() fails for
byte 100..1000 but succeeds for byte 0..9 and 101..1GB, how do you
detect that unless you either test the return value of putc()?

Bjrn

--
Looking for an embeddable web server?
http://www.metasystems.no/products/highlander/index.html

On Tue, 29 May 2007 21:38:05 +0200, "B. Augestad" wrote:
>Roland Pibinger wrote:
>> The implementation must be fast for the usual successful case, not the
>> rare error case. The code assumes that putc() and getc() are macros
>> (i.e. they are nor called).

>Are you advocating that we drop error checking because it slows down the
>'usual successful case'?

Error checking is done by ferror().

>> Partial copies are avoided by using a
>> temporal file(name) as destination which is renamed after successful
>> completion of the copy operation.

>How does that help? If the code is used to copy 1GB and putc() fails for
>byte 100..1000 but succeeds for byte 0..9 and 101..1GB, how do you
>detect that unless you either test the return value of putc()?

It doesn't work that way. After an error the stream remains in the
error state unless clearerr() is called. But admittedly it's not very
elegant to continue 'calling' putc() after an error. I'd probably
prefer fread() and fwrite() to getc() and putc().

--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

Good thinking, thanks. I never tought of it that way, but you're right.

> But admittedly it's not very
> elegant to continue 'calling' putc() after an error. I'd probably
> prefer fread() and fwrite() to getc() and putc().

Or maybe even some platform specific solution never to be mentioned in
c.l.c? ;-)

Bjrn

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc