Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!elroy.jpl.nasa.gov!jarthur!uunet!mcsun!hp4nl!utrcu1!infnews!ramaer
From: ramaer@cs.utwente.nl (Mark Ramaer)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Problem with my C program to copy files between floppies
Message-ID: <1991Apr23.124510@cs.utwente.nl>
Date: 23 Apr 91 10:45:10 GMT
References: <1991Apr21.210056.5685@ccu.umanitoba.ca>
Sender: ramaer@cs (Mark Ramaer)
Organization: University of Twente, Dept. of Computer Science
Lines: 39
Originator: ramaer@utis61


In article <1991Apr21.210056.5685@ccu.umanitoba.ca>, umochock@ccu.umanitoba.ca (Russell Ochocki) writes:
|> [deleted]
|> I try to Malloc a buffer equal to the size of the file being copyied.  Then I
|> do a Fread from the source file, prompt the user to swap disks, fopen the
|> destination file, and Fwrite the contents of the buffer.  And, fclose both
|> files.  Note: I needed to use Malloc, Fread, and Fwrite since I required long
|> ints (not the short expected by malloc, fread, and fwrite).
|> 
|> If I can't Malloc the space I need, I try to Malloc 1/2 as much, and then Fread
|> the first half, Fwrite the first half, Fread the last half (and this is where
|> my problem is), and Fwrite the last half.  (I do it in two passes.)
|> [deleted]
|> It doesn't work when you:
|> 
|>   o Copy a file from disk to disk than requires two or more passes.  The second
|>     Fread on the source file returns 0 bytes read.  Checked ferror but it is
|>     also zero.
|> 
|> So (and here's my point), I have two files open simulatiously, both in drive
|> a:, but on different disks.  And the ST does not seem to like it.  Anyone ever
|> try this?  Does TOS allow this?  Or, is it a bug in my program?
|> 

I have no answers to your questions but
you can probably avoid the problem in the following way:

Fopen - Fread x bytes - Fclose!!!
	prompt
Fopen - Fwrite x bytes - Fclose
	prompt
Fopen - Fseek to position x - Fread - Fclose
	prompt
Fopen - Fseek to the end - Fwrite - Fclose
	.
	.
	.

hope this helps,
Mark