copying files

[David Thompson]

Hans Vlems <[email protected]> wrote:

see below

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).

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
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>

 

[David Thompson]

see below.

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).

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.

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.