File Handling

Every file operation follows the same three-step pattern.

1. OPEN the file — get a handle to it and tell the OS what you'll do (read, write or append).

OPENFILE "data.txt" FOR READ

2. USE the file — read from or write to it.

READFILE "data.txt", line     // read into the variable 'line'
WRITEFILE "data.txt", value   // write 'value' to the file

3. CLOSE the file — flush buffered data and release the file resource.

CLOSEFILE "data.txt"

Why CLOSEFILE matters.

• Writes are typically BUFFERED — held in RAM until the buffer fills or the file is closed. Forgetting to close can lose the unflushed data.
• The OS limits the number of files a program can have open simultaneously. Forgetting to close eventually exhausts the limit.
• Other programs may be locked out of the file until you close it.

Cambridge tip. Mark scheme penalises missing CLOSEFILE every time. Make it a habit.

Cambridge tests three file-open modes:

READ. Open for reading. The read pointer starts at the beginning. Each READFILE moves the pointer forward by one record/line.

WRITE. Open for writing. EXISTING CONTENT IS OVERWRITTEN — the file is treated as empty. Each WRITEFILE adds a new record/line.

APPEND. Open for writing, but new data is added at the END. Existing content is preserved. Used for log files, transaction journals, audit trails.

Cambridge tip. When writing a question that asks 'add to an existing file without overwriting', the answer is APPEND, not WRITE.

When you read a file, you usually don't know in advance how many records it has. The EOF function returns TRUE when the read pointer has reached the end.

OPENFILE "names.txt" FOR READ
WHILE NOT EOF("names.txt")
  READFILE "names.txt", Name
  OUTPUT Name
ENDWHILE
CLOSEFILE "names.txt"

Why EOF is important. Letting the program 'know when to stop' makes it work for files of ANY size. Hard-coding a count (FOR Counter ← 1 TO 10) breaks as soon as the file changes.

Common mistake. Reading PAST the end of file generates a run-time error in most languages. Always check EOF BEFORE reading.

Cambridge tip. Mark scheme expects WHILE NOT EOF(...) or equivalent. UNTIL EOF (REPEAT loop) is also accepted but has subtly different behaviour for empty files.

Files give you two things RAM cannot:

1. Persistence. RAM is VOLATILE — when the program ends or the computer is turned off, contents are wiped. Files live on secondary storage (HDD/SSD) and survive. Crucial for:

• User data that must be saved between sessions.
• Logs that need to be reviewed later.
• Configuration that needs to outlive the program.

2. Portability and scale.

• Files can be COPIED between machines, programs, users.
• Files can hold data sets too large to fit in RAM.
• Files become the SHARED FORMAT between programs (CSV between Excel and a Python script, for example).

Trade-offs.

• Files are MUCH slower than RAM (HDD ~100,000× slower; SSD ~100× slower).
• Programs typically load files into memory for fast access, work in RAM, then write back to disk when done.

Cambridge tip. When asked 'why use a file', the expected answer pairs are: PERSISTENCE (survive program/power off) AND PORTABILITY/SCALE (transfer / large data sets).