Big files, little disks (Was: putting drivers on a floppy disk

BUT, if you have the stones to do it, this weeks assignment is to write a file splitter. GOALS: useful utility, practice handling files larger than RAM, understanding working with files that contain characters tha might be misunderstood to be the EOF 1) Write a program that copies a file. Open two files, one for read and one for write. Read byte from the source file, write it to the destination file. GOTO20. Do NOT read the entire file into memory and then start writing [NO CREDIT WILL BE GIVEN FOR THAT], because that will interfere with later steps, such as copying files that are larger than your virtual memory. WARNING: be careful, that SOME language/OS combinations will default to an "ASCII" (or "cooked") mode (which disunirregardless of its inappropriately chosen name is COMPLETELY DISRELATED TO ASCII), and stop at certain characters; you may need to over-ride for "BINARY" ("raw") mode in OPEN or FOPEN. If written properly, this program will impose no limits on file size, other than the existing OS limits. ... <<<< Good try, worthy of (perhaps) 70% credit, but Will fail to make a correct copy of any record-oriented device (mag tape, punched cards, etc) on any traditional mainframe operating system* and even on Unix. Note also that tapes have things called "tape marks" and a correct copier needs to recognise and reproduce the pattern of these and recognise the double TM that indicates the end of valid data on the tape. Read the /manual/ for the main copy utility on a mainframe to see just how many complications can exist (and most manufacturers have their own little extra "tweaks" to further confuse matters) Even dd on unix has quite a mass of options (and, btw, it is the solution to the OPs problem if available - generally speaking use the supplied system utility rather than writing your own unless you are specifically wanting a programming exercise or the system utility has a limitation or bug that makes it not an answer) * I /think/ even MULTICS is likely to get it wrong. The improved version reads a record at a time and writes the same length record. (an even better version uses multiple buffers to keep the two tape drives continuously active) Andy (no, Fred, I'm not getting at you - just pointing out that not all files are Unix "stream of characters". Oh, and for real fun consider structured files like ISAM or Apples "multiple fork" files)