Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #17419 > unrolled thread

copying files

Back to article view | Back to comp.lang.c

Contents

  copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 01:03 -0800
    Re: copying files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-16 01:23 -0800
      Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 01:31 -0800
        Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 03:14 -0800
          Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 09:43 -0800
            Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 14:59 -0800
              Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 15:06 -0800
      Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 03:13 -0800
        Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 09:56 -0800
          Re: copying files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-16 10:11 -0800
            Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 15:11 -0800
              Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 15:21 -0800
                Re: copying files Philip Lantz <prl@canterey.us> - 2012-02-17 09:53 -0800
                  Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-18 07:22 -0800
              Re: copying files Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-17 03:36 -0800
                Re: copying files Willem <willem@toad.stack.nl> - 2012-02-17 22:04 +0000
                  Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-18 07:28 -0800
                    Re: copying files Willem <willem@toad.stack.nl> - 2012-02-18 21:28 +0000
                Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-18 07:19 -0800
          Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 15:02 -0800
    Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 01:34 -0800
      Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 03:27 -0800
        Re: copying files Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-16 17:11 +0000
          Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 14:57 -0800
        Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 09:54 -0800
      Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 06:41 -0800
    Re: copying files JohnF <john@please.see.sig.for.email.com> - 2012-02-16 09:49 +0000
      Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 03:10 -0800
        Re: copying files JohnF <john@please.see.sig.for.email.com> - 2012-02-16 11:52 +0000
          Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 06:56 -0800
            Re: copying files David Thompson <dave.thompson2@verizon.net> - 2012-02-24 04:43 -0500
          Re: copying files Ike Naar <ike@iceland.freeshell.org> - 2012-02-16 16:19 +0000
            Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 14:50 -0800
          Re: copying files David Thompson <dave.thompson2@verizon.net> - 2012-02-24 04:43 -0500
    Re: copying files Nobody <nobody@nowhere.com> - 2012-02-16 10:58 +0000
      Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 09:41 -0800
        Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 14:59 -0800
        Re: copying files Nobody <nobody@nowhere.com> - 2012-02-17 06:25 +0000
    Re: copying files Kleuske <kleuske@nowhere.net> - 2012-02-16 11:15 +0000
      Re: copying files Hans Vlems <hvlems@freenet.de> - 2012-02-16 06:45 -0800
      Re: copying files Keith Thompson <kst-u@mib.org> - 2012-02-16 09:49 -0800

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#17422

Hans Vlems <hvlems@freenet.de> writes:
> I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
> programs, written in C (gcc 4.4.4), must make a copies between
> different filesystems of these pdf files.
> There is AFAIK no library function that does this, which leaves me two
> options:
> 1- use the console interface, i.e. build a command string and pass
> this to system().
> 2- open the file, copy the contents and close the target
> I'd rather avoid option 1 because system runs out of control of my
> program.
> My question is what read and write functions are best suited to copy
> the (binary) pdf files?
> 'Performance is not the main objective, but I want to be sure that the
> copy finished succesfully and accurately.

I'd just invoke the OS's command to copy the files ("cp" on
Unix-like systems, "copy" on Windows, probably something else on
other systems).  It's likely to be at least as fast as anything
you write yourself, and it may preserve metadata (permissions,
etc.) that you're not going to be able to handle in your own code
without considerable difficulty.

I'm not sure why system running "out of control" of your program
should be an issue; can you elaborate?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#17434

On 16 feb, 10:34, Keith Thompson <ks...@mib.org> wrote:
> Hans Vlems <hvl...@freenet.de> writes:
> > I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
> > programs, written in C (gcc 4.4.4), must make a copies between
> > different filesystems of these pdf files.
> > There is AFAIK no library function that does this, which leaves me two
> > options:
> > 1- use the console interface, i.e. build a command string and pass
> > this to system().
> > 2- open the file, copy the contents and close the target
> > I'd rather avoid option 1 because system runs out of control of my
> > program.
> > My question is what read and write functions are best suited to copy
> > the (binary) pdf files?
> > 'Performance is not the main objective, but I want to be sure that the
> > copy finished succesfully and accurately.
>
> I'd just invoke the OS's command to copy the files ("cp" on
> Unix-like systems, "copy" on Windows, probably something else on
> other systems).  It's likely to be at least as fast as anything
> you write yourself, and it may preserve metadata (permissions,
> etc.) that you're not going to be able to handle in your own code
> without considerable difficulty.
>
> I'm not sure why system running "out of control" of your program
> should be an issue; can you elaborate?
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.net/~kst>
>     Will write code for food.
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith, the system(s) we have to work with are connected to disks in a
way that seriously affects performance.
I've seen a file copy last a little over one minute, with a filesize
of approx. 2 MB. A copy may also just fail.
The function described in the OP may be used for several files, say
about 20 and all at least 1 MB in size.
That is certainly tot impressive by todays standards and shouldn't be
a challenge for the underlying hardware.
Unfortunately, these things do fail occasionally and when a copy fails
then system() does not signal that failure.
I'd rather know about it and hence the desire to perform the copy in
my own code. Malcolm's example demonstrates
the various possibilities to signal an error situation.
Hans

[toc] | [prev] | [next] | [standalone]

#17453

Hans Vlems <hvlems@freenet.de> writes:
<snip>
> Keith, the system(s) we have to work with are connected to disks in a
> way that seriously affects performance.
> I've seen a file copy last a little over one minute, with a filesize
> of approx. 2 MB. A copy may also just fail.
> The function described in the OP may be used for several files, say
> about 20 and all at least 1 MB in size.
> That is certainly tot impressive by todays standards and shouldn't be
> a challenge for the underlying hardware.
> Unfortunately, these things do fail occasionally and when a copy fails
> then system() does not signal that failure.
> I'd rather know about it and hence the desire to perform the copy in
> my own code. Malcolm's example demonstrates
> the various possibilities to signal an error situation.

Given your concerns about safety, you may well be working at the wrong
level.  It's perfectly possible for a C program (using standard C IO) to
signal success without a single byte of data hitting the disk.

If your concern for a safe copy is indeed paramount, you will have ask
about OS-level facilities in a suitable group.  Both the OS and the
file-system types that are involved in the copy may have a bearing on
how to get maximum safety.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#17487

On 16 feb, 18:11, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> Hans Vlems <hvl...@freenet.de> writes:
>
> <snip>
>
> > Keith, the system(s) we have to work with are connected to disks in a
> > way that seriously affects performance.
> > I've seen a file copy last a little over one minute, with a filesize
> > of approx. 2 MB. A copy may also just fail.
> > The function described in the OP may be used for several files, say
> > about 20 and all at least 1 MB in size.
> > That is certainly tot impressive by todays standards and shouldn't be
> > a challenge for the underlying hardware.
> > Unfortunately, these things do fail occasionally and when a copy fails
> > then system() does not signal that failure.
> > I'd rather know about it and hence the desire to perform the copy in
> > my own code. Malcolm's example demonstrates
> > the various possibilities to signal an error situation.
>
> Given your concerns about safety, you may well be working at the wrong
> level.  It's perfectly possible for a C program (using standard C IO) to
> signal success without a single byte of data hitting the disk.
>
> If your concern for a safe copy is indeed paramount, you will have ask
> about OS-level facilities in a suitable group.  Both the OS and the
> file-system types that are involved in the copy may have a bearing on
> how to get maximum safety.
>
> --
> Ben.

The procedure, err function, must copy a file and signal an error when
it trips on one.
That's what it does now. It returns 9 different values, eight of them
indicate an error.
Whether anything ever hit spinning metal is another function's task to
figure out, and I agree
that is beyond the scope of this group.

Hans
beyond the scope of this group a

[toc] | [prev] | [next] | [standalone]

#17458

Hans Vlems <hvlems@freenet.de> writes:
> On 16 feb, 10:34, Keith Thompson <ks...@mib.org> wrote:
[...]
>> I'd just invoke the OS's command to copy the files ("cp" on
>> Unix-like systems, "copy" on Windows, probably something else on
>> other systems).  It's likely to be at least as fast as anything
>> you write yourself, and it may preserve metadata (permissions,
>> etc.) that you're not going to be able to handle in your own code
>> without considerable difficulty.
>>
>> I'm not sure why system running "out of control" of your program
>> should be an issue; can you elaborate?
>
> Keith, the system(s) we have to work with are connected to disks in a
> way that seriously affects performance.  I've seen a file copy last a
> little over one minute, with a filesize of approx. 2 MB. A copy may
> also just fail.  The function described in the OP may be used for
> several files, say about 20 and all at least 1 MB in size.  That is
> certainly tot impressive by todays standards and shouldn't be a
> challenge for the underlying hardware.  Unfortunately, these things do
> fail occasionally and when a copy fails then system() does not signal
> that failure.  I'd rather know about it and hence the desire to
> perform the copy in my own code. Malcolm's example demonstrates the
> various possibilities to signal an error situation.

(Please don't quote signatures.)

If your OS file copying command can fail to copy the file and
not signal that failure, then you've got some serious problems.
I'm skeptical that reimplementing file copying in C will avoid
those problems.  You might get better answers in a forum dedicated to
your operating system.

Personally, I probably wouldn't do something like this in C.
I'd probably use Perl, either with system() to invoke "cp", or
using Perl's standard File::Copy module (the latter isn't as prone
to "foo ; rm -rf ~ ; bar.pdf" attacks).  Whether you use Perl or not,
this looks like a job for a scripting language.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#17447

On 16 feb, 13:56, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Keith Thompson <ks...@mib.org> writes:
> >I'd just invoke the OS's command to copy the files ("cp" on
> >Unix-like systems, "copy" on Windows, probably something else on
> >other systems).  It's likely to be at least as fast as anything
>
>   I'd invoke the OS call to copy the file, on Windows it's
>   »CopyFile«. For example, from one of my programs:
>
> #include <windows.h>
> #include <tchar.h>
>
> ...
>
> int filecopy( LPTSTR const target, LPTSTR const source )
> { BOOL const success = CopyFile( source, target, TRUE );
>   int const terminate = success ? 1 : error5();
>   return terminate; }
>
> ...

OK, I tried both John's and Malcom's solutions and they both work
fine, as expected.
There's very little difference in performance between the two. Both
copy 2 MB files
instantly: that is the user hits return and immediately gets a result
printed.
Thanks for your time!

Hans

[toc] | [prev] | [next] | [standalone]

#17425

Hans Vlems <hvlems@freenet.de> wrote:
> I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
> programs, written in C (gcc 4.4.4), must make a copies between
> different filesystems of these pdf files.
> There is AFAIK no library function that does this, which leaves me two
> options:
> 1- use the console interface, i.e. build a command string and pass
> this to system().
> 2- open the file, copy the contents and close the target
> I'd rather avoid option 1 because system runs out of control of my
> program.
> My question is what read and write functions are best suited to copy
> the (binary) pdf files?
> 'Performance is not the main objective, but I want to be sure that the
> copy finished succesfully and accurately.
> Hans

I'm guessing you're already aware of what Malcolm suggested
in preceding followup, and it's not adequate. And since I've
read your posts in comp.os.vms, I'm also guessing we're
talking about an ods-2/5 filesystem at one end, and maybe a
linux ext3, or whatever, at the other. Could you elaborate on
that a little? And does linux have some ods-2/5 support so you
can mount a vms disk? I wasn't aware of that. If you can indeed
just mount it, then by all means try Malcolm's suggestion and
see what happens. Should just work if the ods filesystem support
is any good. Otherwise, how are you intending to even access
the disk? Decnet for linux (note that it's no longer being
very actively supported)? I think that would be the driving
question that dictates an appropriate answer to your question.
So you need to supply all that additional info first.
   By the way, I usually just ftp zipped files back and forth
between vms and linux boxes on my soho lan. Despite your
"out of control" issue, I'd just write a script (using C's
system() if you want the script in C) to do the job, unless
security's some really, really significant issue for your
situation.
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#17430

On 16 feb, 10:49, JohnF <j...@please.see.sig.for.email.com> wrote:
> Hans Vlems <hvl...@freenet.de> wrote:
> > I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
> > programs, written in C (gcc 4.4.4), must make a copies between
> > different filesystems of these pdf files.
> > There is AFAIK no library function that does this, which leaves me two
> > options:
> > 1- use the console interface, i.e. build a command string and pass
> > this to system().
> > 2- open the file, copy the contents and close the target
> > I'd rather avoid option 1 because system runs out of control of my
> > program.
> > My question is what read and write functions are best suited to copy
> > the (binary) pdf files?
> > 'Performance is not the main objective, but I want to be sure that the
> > copy finished succesfully and accurately.
> > Hans
>
> I'm guessing you're already aware of what Malcolm suggested
> in preceding followup, and it's not adequate. And since I've
> read your posts in comp.os.vms, I'm also guessing we're
> talking about an ods-2/5 filesystem at one end, and maybe a
> linux ext3, or whatever, at the other. Could you elaborate on
> that a little? And does linux have some ods-2/5 support so you
> can mount a vms disk? I wasn't aware of that. If you can indeed
> just mount it, then by all means try Malcolm's suggestion and
> see what happens. Should just work if the ods filesystem support
> is any good. Otherwise, how are you intending to even access
> the disk? Decnet for linux (note that it's no longer being
> very actively supported)? I think that would be the driving
> question that dictates an appropriate answer to your question.
> So you need to supply all that additional info first.
>    By the way, I usually just ftp zipped files back and forth
> between vms and linux boxes on my soho lan. Despite your
> "out of control" issue, I'd just write a script (using C's
> system() if you want the script in C) to do the job, unless
> security's some really, really significant issue for your
> situation.
> --
> John Forkosh  ( mailto:  j...@f.com  where j=john and f=forkosh )- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

John,
your investigating powers are impressive! Unfortunately they've led
you into a dead end street...
On a VMS system I wouldn't have had the need to ask a question. VMS
has an IO subsystem (RMS) and a neatly documented API.
And I doubt I'd have used C to solve this problem ;-) since I have a
choice of at least 4 other languages that I'm more
comfortable with...
The project I'm involved in runs on a Windows platform, on Citrix
servers more precisely and I have _no_ provileges on these
systems. The reason I use the (old) DJGPP compiler is that doesn't
need a Windows install process that uses the registry.
The command line interface on WIndows doesn't even come close to what
DCL has to offer. But I digress.

I want to copy pdf files from one windows disk to another, so the
rename() function is useless. Next, I must retain the original file
which is another reason why rename() won't do.
C has a choice of functions to read from and write to diskfiles. I
want to be sure that all content gets copied, unaltered and without
inflating the file too much. One option is to read the input file one
byte at a time and write it until EOF is signalled.
Or read blocks, say 1 kB, and write them. Probably faster but may have
other drawbacks I'm not aware of.
The original post was written with this in mind and that was perhaps
not too smart.

Hans

[toc] | [prev] | [next] | [standalone]

#17438

Hans Vlems <hvlems@freenet.de> wrote:
> JohnF <j...@please.see.sig.for.email.com> wrote:
>> Hans Vlems <hvl...@freenet.de> wrote:
>> > I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
>> > programs, written in C (gcc 4.4.4), must make a copies between
>> > different filesystems of these pdf files.
>> > There is AFAIK no library function that does this, which leaves me two
>> > options:
>> > 1- use the console interface, i.e. build a command string and pass
>> > this to system().
>> > 2- open the file, copy the contents and close the target
>> > I'd rather avoid option 1 because system runs out of control of my
>> > program.
>> > My question is what read and write functions are best suited to copy
>> > the (binary) pdf files?
>> > 'Performance is not the main objective, but I want to be sure that the
>> > copy finished succesfully and accurately.
>> > Hans
>>
>> I'm guessing you're already aware of what Malcolm suggested
>> in preceding followup, and it's not adequate. And since I've
>> read your posts in comp.os.vms, I'm also guessing we're
>> talking about an ods-2/5 filesystem at one end, and maybe a
>> linux ext3, or whatever, at the other. Could you elaborate on
>> that a little? And does linux have some ods-2/5 support so you
>> can mount a vms disk? I wasn't aware of that. If you can indeed
>> just mount it, then by all means try Malcolm's suggestion and
>> see what happens. Should just work if the ods filesystem support
>> is any good. Otherwise, how are you intending to even access
>> the disk? Decnet for linux (note that it's no longer being
>> very actively supported)? I think that would be the driving
>> question that dictates an appropriate answer to your question.
>> So you need to supply all that additional info first.
>> ? ?By the way, I usually just ftp zipped files back and forth
>> between vms and linux boxes on my soho lan. Despite your
>> "out of control" issue, I'd just write a script (using C's
>> system() if you want the script in C) to do the job, unless
>> security's some really, really significant issue for your
>> situation.
>> --
>> John Forkosh ( mailto: j@f.com where j=john and f=forkosh )

> John,
> your investigating powers are impressive!
Indeed they are!
> Unfortunately they've led you into a dead end street...
Indeed they do!

> On a VMS system I wouldn't have had the need to ask a question. VMS
> has an IO subsystem (RMS) and a neatly documented API.
> And I doubt I'd have used C to solve this problem ;-) since I have a
> choice of at least 4 other languages that I'm more
> comfortable with...
> The project I'm involved in runs on a Windows platform, on Citrix
> servers more precisely and I have _no_ provileges on these
> systems. The reason I use the (old) DJGPP compiler is that doesn't
> need a Windows install process that uses the registry.
> The command line interface on WIndows doesn't even come close to what
> DCL has to offer. But I digress.
> 
> I want to copy pdf files from one windows disk to another, so the
> rename() function is useless. Next, I must retain the original file
> which is another reason why rename() won't do.
> C has a choice of functions to read from and write to diskfiles. I
> want to be sure that all content gets copied, unaltered and without
> inflating the file too much. One option is to read the input file one
> byte at a time and write it until EOF is signalled.
> Or read blocks, say 1 kB, and write them. Probably faster but may have
> other drawbacks I'm not aware of.
> The original post was written with this in mind and that was perhaps
> not too smart.
> Hans

Yeah, I've used djgpp and mingw to compile C programs on windows.
I think I'd recommend mingw if that works for you (I say "think"
because I can't recall >>why<< I prefer it). Anyway, when you say
>>no<< priviliges, I assume your program can read and write files,
i.e., whoever's running it has whatever's necessary to do that.
   In that case, block reads and writes are fine. I've done that
and it works okay for me. Of course, you should try it yourself,
since only God knows what'll happen in your particular situation.
But I think you can safely start with something of the form...

int	fcopy( char *infile, char *outfile ) {
FILE    *inptr = fopen(infile,"rb"),	/*open file for binary read*/
	*outptr = fopen(outfile,"wb");	/*and write*/
unsigned char buff[256];		/*block of bytes from infile*/
int     buflen=255, nread=0,nwrite=0,	/*#bytes we try to read/write*/
	nrw = 0;			/*total bytes read/written*/
if ( inptr!=NULL && outptr!=NULL ) {	/*have opened files*/
  while ( 1 ) {				/*read & write them till eof*/
    /* --- read bytes from infile --- */
    nread = fread(buff,sizeof(unsigned char),buflen,inptr); /*read*/
    if ( nread < 1 ) break;		/* no bytes left in file */
    /* --- write bytes to outfile --- */
    nwrite = fwrite(buff,sizeof(unsigned char),nread,outptr); /*write*/
    if ( nwrite != nread ) { nrw=(-1); break; } /*problem writing*/
    nrw += nwrite;			/*total #bytes*/
    if ( nread < buflen ) break;	/* no bytes left in file */
    } /* --- end-of-while(1) --- */
  fclose(inptr); fclose(outptr);	/* close files */
  } /* --- end-of-if(fileptrs!=NULL) --- */
return ( nrw );				/*back to caller with file size*/
} /* --- end-of-function fcopy() --- */

...which I've snipped from some code that works (with a few
essentially cosmetic changes so it reads okay as a code fragment).
-- 
John Forkosh  ( mailto:  j@f.com  where j=john and f=forkosh )

[toc] | [prev] | [next] | [standalone]

#17446

On 16 feb, 12:52, JohnF <j...@please.see.sig.for.email.com> wrote:
> Hans Vlems <hvl...@freenet.de> wrote:
> > JohnF <j...@please.see.sig.for.email.com> wrote:
> >> Hans Vlems <hvl...@freenet.de> wrote:
> >> > I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
> >> > programs, written in C (gcc 4.4.4), must make a copies between
> >> > different filesystems of these pdf files.
> >> > There is AFAIK no library function that does this, which leaves me two
> >> > options:
> >> > 1- use the console interface, i.e. build a command string and pass
> >> > this to system().
> >> > 2- open the file, copy the contents and close the target
> >> > I'd rather avoid option 1 because system runs out of control of my
> >> > program.
> >> > My question is what read and write functions are best suited to copy
> >> > the (binary) pdf files?
> >> > 'Performance is not the main objective, but I want to be sure that the
> >> > copy finished succesfully and accurately.
> >> > Hans
>
> >> I'm guessing you're already aware of what Malcolm suggested
> >> in preceding followup, and it's not adequate. And since I've
> >> read your posts in comp.os.vms, I'm also guessing we're
> >> talking about an ods-2/5 filesystem at one end, and maybe a
> >> linux ext3, or whatever, at the other. Could you elaborate on
> >> that a little? And does linux have some ods-2/5 support so you
> >> can mount a vms disk? I wasn't aware of that. If you can indeed
> >> just mount it, then by all means try Malcolm's suggestion and
> >> see what happens. Should just work if the ods filesystem support
> >> is any good. Otherwise, how are you intending to even access
> >> the disk? Decnet for linux (note that it's no longer being
> >> very actively supported)? I think that would be the driving
> >> question that dictates an appropriate answer to your question.
> >> So you need to supply all that additional info first.
> >> ? ?By the way, I usually just ftp zipped files back and forth
> >> between vms and linux boxes on my soho lan. Despite your
> >> "out of control" issue, I'd just write a script (using C's
> >> system() if you want the script in C) to do the job, unless
> >> security's some really, really significant issue for your
> >> situation.
> >> --
> >> John Forkosh ( mailto: j...@f.com where j=john and f=forkosh )
> > John,
> > your investigating powers are impressive!
> Indeed they are!
> > Unfortunately they've led you into a dead end street...
>
> Indeed they do!
>
>
>
>
>
> > On a VMS system I wouldn't have had the need to ask a question. VMS
> > has an IO subsystem (RMS) and a neatly documented API.
> > And I doubt I'd have used C to solve this problem ;-) since I have a
> > choice of at least 4 other languages that I'm more
> > comfortable with...
> > The project I'm involved in runs on a Windows platform, on Citrix
> > servers more precisely and I have _no_ provileges on these
> > systems. The reason I use the (old) DJGPP compiler is that doesn't
> > need a Windows install process that uses the registry.
> > The command line interface on WIndows doesn't even come close to what
> > DCL has to offer. But I digress.
>
> > I want to copy pdf files from one windows disk to another, so the
> > rename() function is useless. Next, I must retain the original file
> > which is another reason why rename() won't do.
> > C has a choice of functions to read from and write to diskfiles. I
> > want to be sure that all content gets copied, unaltered and without
> > inflating the file too much. One option is to read the input file one
> > byte at a time and write it until EOF is signalled.
> > Or read blocks, say 1 kB, and write them. Probably faster but may have
> > other drawbacks I'm not aware of.
> > The original post was written with this in mind and that was perhaps
> > not too smart.
> > Hans
>
> Yeah, I've used djgpp and mingw to compile C programs on windows.
> I think I'd recommend mingw if that works for you (I say "think"
> because I can't recall >>why<< I prefer it). Anyway, when you say>>no<< priviliges, I assume your program can read and write files,
>
> i.e., whoever's running it has whatever's necessary to do that.
>    In that case, block reads and writes are fine. I've done that
> and it works okay for me. Of course, you should try it yourself,
> since only God knows what'll happen in your particular situation.
> But I think you can safely start with something of the form...
>
> int     fcopy( char *infile, char *outfile ) {
> FILE    *inptr = fopen(infile,"rb"),  /*open file for binary read*/
>         *outptr = fopen(outfile,"wb");        /*and write*/
> unsigned char buff[256];                /*block of bytes from infile*/
> int     buflen=255, nread=0,nwrite=0,   /*#bytes we try to read/write*/
>         nrw = 0;                        /*total bytes read/written*/
> if ( inptr!=NULL && outptr!=NULL ) {    /*have opened files*/
>   while ( 1 ) {                         /*read & write them till eof*/
>     /* --- read bytes from infile --- */
>     nread = fread(buff,sizeof(unsigned char),buflen,inptr); /*read*/
>     if ( nread < 1 ) break;          /* no bytes left in file */
>     /* --- write bytes to outfile --- */
>     nwrite = fwrite(buff,sizeof(unsigned char),nread,outptr); /*write*/
>     if ( nwrite != nread ) { nrw=(-1); break; } /*problem writing*/
>     nrw += nwrite;                      /*total #bytes*/
>     if ( nread < buflen ) break;     /* no bytes left in file */
>     } /* --- end-of-while(1) --- */
>   fclose(inptr); fclose(outptr);        /* close files */
>   } /* --- end-of-if(fileptrs!=NULL) --- */
> return ( nrw );                         /*back to caller with file size*/
>
> } /* --- end-of-function fcopy() --- */
>
> ...which I've snipped from some code that works (with a few
> essentially cosmetic changes so it reads okay as a code fragment).
> --
> John Forkosh  ( mailto:  j...@f.com  where j=john and f=forkosh )- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -- Tekst uit oorspronkelijk bericht niet weergeven -
>
> - Tekst uit oorspronkelijk bericht weergeven -

The reason I use djgpp is that it is *very* simple to set up: unpack a
zip file and that's it.
Much later I came across mingw and that proved not as easy to set up.
Since I don't write code that is so subtle that it takes a very
refined compiler I think that gcc 4.4.4 is quite alright.

Hans

[toc] | [prev] | [next] | [standalone]

#17876

 On Thu, 16 Feb 2012 06:56:15 -0800 (PST), Hans Vlems
<hvlems@freenet.de> wrote:

> On 16 feb, 12:52, JohnF <j...@please.see.sig.for.email.com> wrote:
> > Hans Vlems <hvl...@freenet.de> wrote:
<snip>
> > > The project I'm involved in runs on a Windows platform, on Citrix
> > > servers more precisely and I have _no_ provileges on these
> > > systems. The reason I use the (old) DJGPP compiler is that doesn't
> > > need a Windows install process that uses the registry.

see below.

> > > I want to copy pdf files from one windows disk to another, so the
> > > rename() function is useless. Next, I must retain the original file
> > > which is another reason why rename() won't do.
> > > C has a choice of functions to read from and write to diskfiles. I

C stdio has several functions, but they all work together. fread and
fgets are 'as if' a series of fgetc, and fwrite and fputs and fprintf
are 'as if' fputc. Normally a C library should do I/O as well as the
underlying OS allows, but if there is a problem it will probably
affect all calls. In particular, if there is a problem with write
caching or buffering, as discussed upthread, using different stdio
calls is unlikely to fix it.

C can also call most OSes directly, particularly including Windows,
but that is OS-specific (of course).

> > > want to be sure that all content gets copied, unaltered and without
> > > inflating the file too much. One option is to read the input file one
> > > byte at a time and write it until EOF is signalled.
> > > Or read blocks, say 1 kB, and write them. Probably faster but may have
> > > other drawbacks I'm not aware of.

I don't know what you mean by 'inflating'. C will normally read
exactly what's in an input file, and write exactly what you tell it,
so if you write what you read you should get an exact copy, except for
metadata like time-modified.

Pedantically, the C standard does permit padding at the end of a
binary file, and some restrictions on a text file, to allow for some
past OSes that needed such restrictions. Windows does not have these
issues and any Windows C library that doesn't read and write binary
exactly is just defective (and text except for the silly ^Z).

If the file system does compression that is invisible to C. If you
read a compressed file and write it uncompressed it may take more
space, and if you read an uncompressed file and write it compressed it
may take less. OTOH pdf can be and usually is internally compressed so
filesystem or other outside compression usually is less effective.

> > Yeah, I've used djgpp and mingw to compile C programs on windows.
> > I think I'd recommend mingw if that works for you (I say "think"
> > because I can't recall >>why<< I prefer it). Anyway, when you say
> > >>no<< priviliges, I assume your program can read and write files,
> > i.e., whoever's running it has whatever's necessary to do that.

> The reason I use djgpp is that it is *very* simple to set up: unpack a
> zip file and that's it.

mingw can be pretty simple too. If you don't like the mingw installer,
and I don't, you can just download the runtime and optionally dev
package(s) and un-tgz. No registry and no fiddling menus etc. except
for 'msys' which isn't needed here. tgz is a chicken-and-egg problem,
but I recommend WinZip which I like for other reasons anyway.

> Much later I came across mingw and that proved not as easy to set up.
> Since I don't write code that is so subtle that it takes a very
> refined compiler I think that gcc 4.4.4 is quite alright.
> 
For I/O, the compiler doesn't matter as much as the library. djgpp has
a full C library since it assumes only DOS underneath, even though
nowadays 'DOS' is actually Windows emulation (ntvdm). mingw mostly
just uses Microsoft's 'Visual C' (classic) library msvcrt.dll which is
in every Windows since about 2k.

[toc] | [prev] | [next] | [standalone]

#17450

On 2012-02-16, JohnF <john@please.see.sig.for.email.com> wrote:
> int	fcopy( char *infile, char *outfile ) {
> FILE    *inptr = fopen(infile,"rb"),	/*open file for binary read*/
> 	*outptr = fopen(outfile,"wb");	/*and write*/
> unsigned char buff[256];		/*block of bytes from infile*/
> int     buflen=255, nread=0,nwrite=0,	/*#bytes we try to read/write*/
> 	nrw = 0;			/*total bytes read/written*/
> if ( inptr!=NULL && outptr!=NULL ) {	/*have opened files*/
>   while ( 1 ) {				/*read & write them till eof*/
>     /* --- read bytes from infile --- */
>     nread = fread(buff,sizeof(unsigned char),buflen,inptr); /*read*/

sizeof(unsigned char) is 1 by definition.
Is there a particular reason why you are reading one byte less than
the size of the buffer? It seems more logical to use the entire buffer:

  nread = fread(buff, 1, sizeof buff, inptr);

>     if ( nread < 1 ) break;		/* no bytes left in file */
>     /* --- write bytes to outfile --- */
>     nwrite = fwrite(buff,sizeof(unsigned char),nread,outptr); /*write*/
>     if ( nwrite != nread ) { nrw=(-1); break; } /*problem writing*/
>     nrw += nwrite;			/*total #bytes*/
>     if ( nread < buflen ) break;	/* no bytes left in file */

  if (nread < sizeof buff) break;

>     } /* --- end-of-while(1) --- */
>   fclose(inptr); fclose(outptr);	/* close files */
>   } /* --- end-of-if(fileptrs!=NULL) --- */
> return ( nrw );				/*back to caller with file size*/

Potential file descriptor leak: if one of the files could be opened
but the other couldn't, the opened file is not closed.
Also, in this case 0 is returned, so from the return value you
cannot distinguish between having fopen errors, and having completed
a successful copy of an empty file.

> } /* --- end-of-function fcopy() --- */
>
> ...which I've snipped from some code that works (with a few
> essentially cosmetic changes so it reads okay as a code fragment).

[toc] | [prev] | [next] | [standalone]

#17486

On 16 feb, 17:19, Ike Naar <i...@iceland.freeshell.org> wrote:
> On 2012-02-16, JohnF <j...@please.see.sig.for.email.com> wrote:
>
> > int        fcopy( char *infile, char *outfile ) {
> > FILE    *inptr = fopen(infile,"rb"),     /*open file for binary read*/
> >    *outptr = fopen(outfile,"wb");        /*and write*/
> > unsigned char buff[256];           /*block of bytes from infile*/
> > int     buflen=255, nread=0,nwrite=0,      /*#bytes we try to read/write*/
> >    nrw = 0;                        /*total bytes read/written*/
> > if ( inptr!=NULL && outptr!=NULL ) {       /*have opened files*/
> >   while ( 1 ) {                            /*read & write them till eof*/
> >     /* --- read bytes from infile --- */
> >     nread = fread(buff,sizeof(unsigned char),buflen,inptr); /*read*/
>
> sizeof(unsigned char) is 1 by definition.
> Is there a particular reason why you are reading one byte less than
> the size of the buffer? It seems more logical to use the entire buffer:
>
>   nread = fread(buff, 1, sizeof buff, inptr);
>
> >     if ( nread < 1 ) break;             /* no bytes left in file */
> >     /* --- write bytes to outfile --- */
> >     nwrite = fwrite(buff,sizeof(unsigned char),nread,outptr); /*write*/
> >     if ( nwrite != nread ) { nrw=(-1); break; } /*problem writing*/
> >     nrw += nwrite;                 /*total #bytes*/
> >     if ( nread < buflen ) break;        /* no bytes left in file */
>
>   if (nread < sizeof buff) break;
>
> >     } /* --- end-of-while(1) --- */
> >   fclose(inptr); fclose(outptr);   /* close files */
> >   } /* --- end-of-if(fileptrs!=NULL) --- */
> > return ( nrw );                            /*back to caller with file size*/
>
> Potential file descriptor leak: if one of the files could be opened
> but the other couldn't, the opened file is not closed.
> Also, in this case 0 is returned, so from the return value you
> cannot distinguish between having fopen errors, and having completed
> a successful copy of an empty file.
>
>
>
>
>
>
>
> > } /* --- end-of-function fcopy() --- */
>
> > ...which I've snipped from some code that works (with a few
> > essentially cosmetic changes so it reads okay as a code fragment).

Hi Ike, what I did was a blend of both solutions: I didn't care for
the goto's and the lack of error handling. So the result is pretty
robust. My code doesn't even come near the Internet and system
security is not my concern. Poor platform design, however, is
unfortunately and in this day and age ....
Hans

[toc] | [prev] | [next] | [standalone]

#17875

On Thu, 16 Feb 2012 11:52:34 +0000 (UTC), JohnF
<john@please.see.sig.for.email.com> wrote:

> Hans Vlems <hvlems@freenet.de> wrote:
<snip>
> > The project I'm involved in runs on a Windows platform, on Citrix
> > servers more precisely and I have _no_ provileges on these
> > systems. The reason I use the (old) DJGPP compiler is that doesn't
> > need a Windows install process that uses the registry. <snip>

see below

> > I want to copy pdf files from one windows disk to another, so the
> > rename() function is useless. Next, I must retain the original file
> > which is another reason why rename() won't do.
> > C has a choice of functions to read from and write to diskfiles. I

C stdio has several functions, but they all work the same way. fread
and fgets are "as if" a series of fgetc, and fwrite and fputs and
fprintf are "as if" fputc. Normally a C library will do I/O as well as
the underlying OS allows, but if there is a problem it will probably
affect all calls equally. In particular, if there is a problem with
write caching or buffering, as discussed upthread, using different
stdio calls is unlikely to make any difference.

C can also call most OSes directly, particularly including Windows,
but that is OS-specific (of course).

> > want to be sure that all content gets copied, unaltered and without
> > inflating the file too much. One option is to read the input file one
> > byte at a time and write it until EOF is signalled.
> > Or read blocks, say 1 kB, and write them. Probably faster but may have
> > other drawbacks I'm not aware of.

I don't know what you mean by 'inflating'. C will normally read
exactly what's in an input file, and write exactly what you tell it,
so if you write what you read you should get an exact copy. 

Pedantically, the C standard does allow some padding at the end of a
binary file, and various restrictions on a text file, to allow for
some past OSes that imposed such restrictions. Windows does not have
these issues and any Windows C library that doesn't read and write
exactly is just defective.

> Yeah, I've used djgpp and mingw to compile C programs on windows.
> I think I'd recommend mingw if that works for you (I say "think"
> because I can't recall >>why<< I prefer it). Anyway, when you say
> >>no<< priviliges, I assume your program can read and write files,
> i.e., whoever's running it has whatever's necessary to do that.
>    In that case, block reads and writes are fine. I've done that
> and it works okay for me. Of course, you should try it yourself,
> since only God knows what'll happen in your particular situation.
> But I think you can safely start with something of the form...
<snip>

[toc] | [prev] | [next] | [standalone]

#17429

On Thu, 16 Feb 2012 01:03:12 -0800, Hans Vlems wrote:

> I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
> programs, written in C (gcc 4.4.4), must make a copies between
> different filesystems of these pdf files.
> There is AFAIK no library function that does this, which leaves me two
> options:
> 1- use the console interface, i.e. build a command string and pass
> this to system().

Avoid system() unless executing a "canned" command supplied by the user.
If you need to spawn a child process with specific arguments, use fork()
and exec*() rather than attempting to construct a shell command.

> 2- open the file, copy the contents and close the target

First, you need to decide what you mean by "copy". Part of the reason that
there isn't a library function is that there isn't a single obvious
definition of what it means to copy a file. Two plausible choices are:

1. open() the destination, write the contents of the source to it, close()
it.

2. open() a temporary file in the same directory as the destination,
write the contents of the source to it, close() it, rename() it over the
original.

The two alternatives have many differences, including (but not limited to):

1. If there are multiple hard links to the destination, #1 will leave all
links intact, and all will refer to the modified file. #2 will break one
specific hard link, causing the filename to point to a new file; the
others will still refer to the original file.

2. If the destination file is open in some other process, #1 will cause
the process to immediately see the new contents, while #2 will only affect
processes which open() the file after the rename() has occurred.

3. #1 requires that you have write permission on the destination file if
it exists, or write permission on the directory if it doesn't. #2 requires
that you have write permission on the directory (the file's permissions
don't matter); if the destination exists and the directory has the sticky
bit set, you must own the file (or be root).

4. #1 won't affect the owner, group or permissions of an existing file. #2
will create a new file with your uid, primary gid and umask.

5. If the destination exists and is a device (block or character) or FIFO,
#1 will open() it and write to it. #2 will replace it with a file.

6. If the destination exists and is a symlink, #1 will open() it (i.e.
open its target) and write to it. #2 will replace it with a file.

Note that the Unix "cp" command is similar to option #1, except that if
the file exists but open()ing it fails and the "-f" flag is used, it
attempts to unlink() it then, if that succeeds, proceeds as if the file
didn't exist.

> I'd rather avoid option 1 because system runs out of control of my
> program.
> My question is what read and write functions are best suited to copy
> the (binary) pdf files?
> 'Performance is not the main objective, but I want to be sure that the
> copy finished succesfully and accurately.

For robustness, choose option #2 above. If writing the file fails,
remove() the temporary file rather than rename()ing it. The original file
will be left intact.

Performance-wise, mmap()ing the source and write()ing directly from the
mmap()d region eliminates a copy. mmap()ing both source and destination
and memcpy()ing may or may nor provide any additional benefit.

[toc] | [prev] | [next] | [standalone]

#17455

Nobody <nobody@nowhere.com> writes:
> On Thu, 16 Feb 2012 01:03:12 -0800, Hans Vlems wrote:
>> I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
>> programs, written in C (gcc 4.4.4), must make a copies between
>> different filesystems of these pdf files.
>> There is AFAIK no library function that does this, which leaves me two
>> options:
>> 1- use the console interface, i.e. build a command string and pass
>> this to system().
>
> Avoid system() unless executing a "canned" command supplied by the user.
> If you need to spawn a child process with specific arguments, use fork()
> and exec*() rather than attempting to construct a shell command.
[...]

This, as well as the rest of your response, relies heavily on the
assumption that the OP is on a Unix-like system.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#17488

On 16 feb, 18:41, Keith Thompson <ks...@mib.org> wrote:
> Nobody <nob...@nowhere.com> writes:
> > On Thu, 16 Feb 2012 01:03:12 -0800, Hans Vlems wrote:
> >> I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
> >> programs, written in C (gcc 4.4.4), must make a copies between
> >> different filesystems of these pdf files.
> >> There is AFAIK no library function that does this, which leaves me two
> >> options:
> >> 1- use the console interface, i.e. build a command string and pass
> >> this to system().
>
> > Avoid system() unless executing a "canned" command supplied by the user.
> > If you need to spawn a child process with specific arguments, use fork()
> > and exec*() rather than attempting to construct a shell command.
>
> [...]
>
> This, as well as the rest of your response, relies heavily on the
> assumption that the OP is on a Unix-like system.
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org  <http://www.ghoti.net/~kst>
>     Will write code for food.
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith, I have to deal with a Windows Server 2003 box which is hardly
at the top of my list of favorites :-)

[toc] | [prev] | [next] | [standalone]

#17498

On Thu, 16 Feb 2012 09:41:42 -0800, Keith Thompson wrote:

>> Avoid system() unless executing a "canned" command supplied by the user.
>> If you need to spawn a child process with specific arguments, use fork()
>> and exec*() rather than attempting to construct a shell command.
> [...]
> 
> This, as well as the rest of your response, relies heavily on the
> assumption that the OP is on a Unix-like system.

True, but "equivalent" issues exist on other platforms. If anything,
Windows is even worse (both on the system() issue and on filesystem
semantics).

[toc] | [prev] | [next] | [standalone]

#17432

On Thu, 16 Feb 2012 01:03:12 -0800, Hans Vlems saw fit to publish the
following:

> I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
> programs, written in C (gcc 4.4.4), must make a copies between different
> filesystems of these pdf files. There is AFAIK no library function that
> does this, which leaves me two options:
> 1- use the console interface, i.e. build a command string and pass this
> to system().

Don't. It's ineffective and may open up your system to abuse.


> 2- open the file, copy the contents and close the target I'd rather
> avoid option 1 because system runs out of control of my program.
> My question is what read and write functions are best suited to copy the
> (binary) pdf files?

Try fopen, fread, fwrite and fclose. Use a big buffer, since PDF's (especially
with grahics) tend to be big.

> 'Performance is not the main objective, but I want to be sure that the
> copy finished succesfully and accurately. Hans

Check for error codes.

-- 
Each kiss is as the first.
		-- Miramanee, Kirk's wife, "The Paradise Syndrome",
		   stardate 4842.6

[toc] | [prev] | [next] | [standalone]

#17445

On 16 feb, 12:15, Kleuske <kleu...@nowhere.net> wrote:
> On Thu, 16 Feb 2012 01:03:12 -0800, Hans Vlems saw fit to publish the
> following:
>
> > I'm maintaing large numbers of Adobe Reader files (.pdf). One of my
> > programs, written in C (gcc 4.4.4), must make a copies between different
> > filesystems of these pdf files. There is AFAIK no library function that
> > does this, which leaves me two options:
> > 1- use the console interface, i.e. build a command string and pass this
> > to system().
>
> Don't. It's ineffective and may open up your system to abuse.
>
> > 2- open the file, copy the contents and close the target I'd rather
> > avoid option 1 because system runs out of control of my program.
> > My question is what read and write functions are best suited to copy the
> > (binary) pdf files?
>
> Try fopen, fread, fwrite and fclose. Use a big buffer, since PDF's (especially
> with grahics) tend to be big.
>
> > 'Performance is not the main objective, but I want to be sure that the
> > copy finished succesfully and accurately. Hans
>
> Check for error codes.
>
> --
> Each kiss is as the first.
>                 -- Miramanee, Kirk's wife, "The Paradise Syndrome",
>                    stardate 4842.6

Given the quality and performance of the disks on the systems we've
got to work with
error checking is my main objective here. Performance is not my main
concern right.
However once the hardware problems get solved, performance may just
become user issue #1 again.
Hans

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web