umochock@ccu.umanitoba.ca (Russell Ochocki) (04/22/91)
For my first useful C program on my STe, I wrote a program to copy files from
one disk to another. I was tired of using a ram disk every time I wanted to
copy a file to a different disk (since I have only one disk drive).
I'm using Sozobon C with gulam as my shell.
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.)
I tested the thing to death and it works under the following situations:
o Copy a file that is smaller than available memory (i.e. only one disk swap
needed).
o Copy a file larger than available memory from a ram disk to drive a:.
This works with two or even 10 swaps. The swapping is simulated here but
does verify that my code to read and write the file in as many pieces as
needed works just fine.
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?
Any help would be appreciated.
--
|
| \/ Russell Ochocki, University of Manitoba
| _/\_ Winnipeg, Manitoba, Canada (umochock@ccu.umanitoba.ca)
|wallace@oldtmr.enet.dec.com (Ray Wallace) (04/22/91)
In article <1991Apr21.210056.5685@ccu.umanitoba.ca>, umochock@ccu.umanitoba.ca (Russell Ochocki) writes... > >For my first useful C program on my STe, I wrote a program to copy files from >one disk to another. I was tired of using a ram disk every time I wanted to ... >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 You can't just pull a disk out of a drive with an open file on it, UNLESS GEMDOS tells you to. To get GEMDOS to tell you to change disks, change your program to copy files from drive A: to drive B: (yes I know you only have one drive). When your program tries to access drive B: (ie: to open the file) you will get an alert box telling you to put in the other disk into drive A:, when you go back and access drive A: again (ie: to read the second half of the file) then you will get another alert box telling you to change disks again. This should fix your problem. --- Ray Wallace (INTERNET,UUCP) wallace@oldtmr.enet.dec.com (UUCP) ...!decwrl!oldtmr.enet!wallace (INTERNET) wallace%oldtmr.enet@decwrl.dec.com ---
ramaer@cs.utwente.nl (Mark Ramaer) (04/23/91)
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
umochock@ccu.umanitoba.ca (Russell Ochocki) (04/25/91)
To those of you that answered my plea: thanks! A summary of your ideas follows. Several people mentioned using drives a: and b: so the GEM box to switch disks would appear. From the beginning, I was using a: for the source and b: for the destination file but that box never appeared. Thinking it maybe was something gulam was doing, I tried running it from the desktop -- still no boxes. On a hunch, I renamed the executable from .ttp to .prg and well-what-da-ya-know it worked! ---- but only from the desktop, not inside gulam. Try ls a:; ls b: in gulam -- I don't get the box. I tried b: in mupfel though and I did get the box to switch disks. Gulam must be suppressing this box. How can I re-activate the box? Others mentioned flushing the I/O buffers with Mediach() and making sure the ST got the media change with Getbpb(). This didn't make a difference -- still no alert box. The adventure continues.... -- | | \/ Russell Ochocki, University of Manitoba | _/\_ Winnipeg, Manitoba, Canada (umochock@ccu.umanitoba.ca) |
erlingh@idt.unit.no (Erling Henanger) (04/26/91)
In article <1991Apr25.054417.21973@ccu.umanitoba.ca>, umochock@ccu.umanitoba.ca (Russell Ochocki) writes: |> Gulam must be suppressing this box. How can I re-activate the box? How about: gem your_cp.prg This tells gulam to activate your_cp.prg as a gem-application, and thus should work. |> | |> | \/ Russell Ochocki, University of Manitoba |> | _/\_ Winnipeg, Manitoba, Canada (umochock@ccu.umanitoba.ca) |> | -- _______ _____ o ____ Erling Henanger /___ /____/ / / /| / / Norwegian Institute / /\ / / / | / | ___ of Technology. (NTH) ------ / \ /____ / / |/ \____| o Atari Lives !
ralph@laas.fr (Ralph P. Sobek) (04/26/91)
I also have had severe troubles when accessing drive b: under gulam. My ST would crash. -- Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!laas!ralph If all else fails, try: sobek@eclair.Berkeley.EDU =============================================================================== Proud owner of a Mega 4 ST. Wishing it was a Mega STe! :-|