Sequential and Random Access to File

Programming Language & Its Applications — Pointers, Structure and Data Files in C, NEC licence examination syllabus (Nepal Engineering Council).

Sequential and Random Access to File

Sequential access reads front to back; random access jumps straight to record number 4,182. The difference is fseek.

Every open file has a file position indicator — a byte offset that says where the next read or write will happen. Sequential access just lets it advance. Random access moves it deliberately with fseek, and because a fixed-size record file has a predictable layout, you can compute exactly where any record lives. That one multiplication turns a file into a database.

🌍 Where this lives: this is the difference between streaming a film and scrubbing the timeline. Sequential is how a log file is read, how grep works, how a video plays. Random access is what happens when you drag the player to 42:30 and it starts instantly — the player computed a byte offset and seeked. It is also why an SSD changed everything: on a spinning disk a seek meant physically moving a head (~10 ms); on an SSD it is ~0.1 ms. Databases designed in the 1970s are still shaped by the assumption that seeks are expensive.

The three positioning functions

int fseek(FILE *fp, long offset, int origin); long ftell(FILE *fp); /* current position */ void rewind(FILE *fp); /* = fseek(fp,0,SEEK_SET) + clear error flags */ ORIGINS: SEEK_SET 0 from the BEGINNING of the file SEEK_CUR 1 from the CURRENT position SEEK_END 2 from the END (offset is usually ≤ 0) Examples: fseek(fp, 0, SEEK_SET); → first byte fseek(fp, 28, SEEK_SET); → byte 28 fseek(fp, 0, SEEK_END); → end; ftell now gives the SIZE fseek(fp,-28, SEEK_END); → start of the LAST 28-byte record fseek(fp, 28, SEEK_CUR); → skip forward one record fseek returns 0 on success, non-zero on failure. THE KEY FORMULA for fixed-size records: offset of record n (0-based) = n × sizeof(Record) Record 0 → byte 0 Record 1 → byte 28 Record 5 → byte 140 Record n → byte 28n and inversely: number of records = file_size / sizeof(Record)

Worked example 1 — computing offsets by hand

A file holds Student records where sizeof(Student) = 28 bytes and the file is 1400 bytes long. number of records = 1400 / 28 = 50 valid record indices = 0 .. 49 To read record 17: fseek(fp, 17 * 28, SEEK_SET); → offset 476 fread(&s, 28, 1, fp); after the read, ftell = 476 + 28 = 504 To read the LAST record without knowing the count: fseek(fp, -28, SEEK_END); → offset 1372 fread(&s, 28, 1, fp); To read the 3rd-from-last: fseek(fp, -3*28, SEEK_END); → offset 1316 To UPDATE record 17 in place: fseek(fp, 17*28, SEEK_SET); fwrite(&s, 28, 1, fp); → overwrites exactly those 28 bytes Cost comparison for reaching record 49 of 50: sequential: 49 fread calls, 1372 bytes read random : 1 fseek, 28 bytes read → 49× less I/O

random.c

#include <stdio.h>
#include <string.h>

typedef struct {
    int   roll;
    char  name[20];
    float marks;
} Student;

/* read record n directly - O(1), no scanning */
int read_record(FILE *fp, long n, Student *out) {
    if (fseek(fp, n * (long)sizeof(Student), SEEK_SET) != 0)
        return 0;
    return fread(out, sizeof(Student), 1, fp) == 1;
}

/* update record n IN PLACE - the file does not grow */
int update_record(FILE *fp, long n, const Student *s) {
    if (fseek(fp, n * (long)sizeof(Student), SEEK_SET) != 0)
        return 0;
    return fwrite(s, sizeof(Student), 1, fp) == 1;
}

long record_count(FILE *fp) {
    long here = ftell(fp);
    fseek(fp, 0, SEEK_END);
    long n = ftell(fp) / (long)sizeof(Student);
    fseek(fp, here, SEEK_SET);
    return n;
}

int main(void) {
    /* build a 5-record file */
    Student data[5] = {
        {101,"Ram Bahadur", 87.5f},{102,"Sita Devi",  91.0f},
        {103,"Hari Prasad", 76.5f},{104,"Gita Kumari",68.0f},
        {105,"Bikash Thapa",94.5f}
    };
    FILE *fp = fopen("students.dat", "wb");
    if (!fp) return 1;
    fwrite(data, sizeof(Student), 5, fp);
    fclose(fp);

    /* "r+b" = read AND write, do not truncate */
    fp = fopen("students.dat", "r+b");
    if (!fp) { perror("open"); return 1; }

    printf("sizeof(Student) = %zu\n", sizeof(Student));
    printf("records in file = %ld\n", record_count(fp));

    Student s;
    /* jump straight to record 3 */
    if (read_record(fp, 3, &s))
        printf("rec 3: %d %-14s %.1f  (ftell now %ld)\n",
               s.roll, s.name, s.marks, ftell(fp));

    /* modify it and write it back in place */
    s.marks += 10.0f;
    update_record(fp, 3, &s);
    read_record(fp, 3, &s);
    printf("rec 3 after +10: %.1f\n", s.marks);

    /* the last record, via SEEK_END */
    fseek(fp, -(long)sizeof(Student), SEEK_END);
    fread(&s, sizeof(Student), 1, fp);
    printf("last : %d %-14s %.1f\n", s.roll, s.name, s.marks);

    /* backwards traversal - only possible with fseek */
    printf("reverse order: ");
    for (long i = record_count(fp) - 1; i >= 0; i--) {
        read_record(fp, i, &s);
        printf("%d ", s.roll);
    }
    printf("\n");
    fclose(fp);
    return 0;
}
Output:
sizeof(Student) = 28
records in file = 5
rec 3: 104 Gita Kumari   68.0  (ftell now 112)
rec 3 after +10: 78.0
last : 105 Bikash Thapa  94.5
reverse order: 105 104 103 102 101

Checking the ftell value: record 3 starts at 3 × 28 = 84 after reading 28 bytes: 84 + 28 = 112 ✔ Note "r+b" not "w+b". "w+b" would have TRUNCATED the file we just wrote — a one-character mistake that destroys all the data. Also note update_record does not change the file size. This is the crucial property of fixed-size records: an update is an overwrite, not a rewrite. Changing one record in a 1 GB file touches 28 bytes.

Random access needs fixed-size records. If names were variable-length strings, record 17 could start anywhere and the multiplication would be meaningless. That is why real database files pad records to a fixed width, or keep a separate index mapping keys to byte offsets — which is precisely what a database index is.

Worked example 2 — sequential vs random cost

compare.c

#include <stdio.h>

typedef struct { int roll; char name[20]; float marks; } Student;

/* SEQUENTIAL search: must read every record until match */
long seq_find(FILE *fp, int roll, long *reads) {
    rewind(fp); *reads = 0;
    Student s;
    for (long i = 0; fread(&s, sizeof s, 1, fp) == 1; i++) {
        (*reads)++;
        if (s.roll == roll) return i;
    }
    return -1;
}

/* RANDOM access when the roll number IS the position:
   roll 101 -> record 0, roll 150 -> record 49 */
long direct_find(FILE *fp, int roll, long *reads) {
    long idx = roll - 101;            /* hashing, in effect */
    if (idx < 0) return -1;
    fseek(fp, idx * (long)sizeof(Student), SEEK_SET);
    Student s;
    *reads = 1;
    if (fread(&s, sizeof s, 1, fp) != 1) return -1;
    return s.roll == roll ? idx : -1;
}

int main(void) {
    /* 50 records, rolls 101..150 */
    FILE *fp = fopen("big.dat", "wb");
    for (int i = 0; i < 50; i++) {
        Student s = {101 + i, "", 60.0f + i};
        snprintf(s.name, sizeof s.name, "Student%02d", i+1);
        fwrite(&s, sizeof s, 1, fp);
    }
    fclose(fp);

    fp = fopen("big.dat", "rb");
    long reads;
    printf("looking for roll 149:\n");
    printf("  sequential: index %ld after %ld reads\n",
           seq_find(fp, 149, &reads), reads);
    printf("  direct    : index %ld after %ld read\n",
           direct_find(fp, 149, &reads), reads);
    fclose(fp);
    return 0;
}
Output:
looking for roll 149:
  sequential: index 48 after 49 reads
  direct    : index 48 after 1 read

Scaling this up — finding one record in a file of n: n = 50 sequential 25 avg direct 1 n = 1,000 sequential 500 avg direct 1 n = 1,000,000 sequential 500,000 direct 1 Sequential: O(n) Random with a computable offset: O(1) If the key is NOT the position, you cannot compute the offset — you need an INDEX: a small structure mapping key → byte offset, kept sorted or hashed. binary search on a sorted index: O(log n) seeks n = 1,000,000 → 20 seeks hash index: O(1) expected → 1 seek This is, in one sentence, what a database index does and why creating one makes a slow query fast.

Sequential is not obsolete

Sequential access wins when: · you need EVERY record anyway (totals, reports, exports) · records are VARIABLE length (text, CSV, JSON, logs) · you are streaming (video, audio, a network socket — where you CANNOT seek at all) · the medium is sequential (tape, a pipe, stdin) And crucially: sequential reading is FASTER PER BYTE. Reading 1 GB sequentially from an SSD is ~1-3 seconds. Reading the same 1 GB as 1,000,000 random 1 KB seeks can take 10× longer, because each seek has fixed overhead and defeats read-ahead prefetching. So the real rule is not "random access is better". It is: need ONE record → seek to it need ALL records → stream them sequentially

🌍 Go further: this trade-off is live and current. Log-structured merge trees — the storage engine behind Cassandra, RocksDB, and LevelDB — deliberately give up in-place updates so that all writes become sequential appends, then merge the files in the background. They chose the "slower" access pattern on paper and got much faster writes in practice. Look up "LSM tree vs B-tree write amplification"; it is the same fseek-versus-stream decision you just learned, scaled to petabytes.

💡 Exam angle: the offset formula n × sizeof(Record) and its inverse size / sizeof(Record) are near-certain numericals — practise with SEEK_SET, SEEK_CUR and SEEK_END, including negative offsets. Know the three origin constants, that ftell after fseek(fp,0,SEEK_END) gives the file size, and that random access requires fixed-length records. Be ready to compare sequential O(n) with direct O(1) access and to say when sequential is still the right choice.

Syllabus points

fseek, ftell, rewind

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.