fseeko not creating a hole in file when seeking after EOF

Question

I'm trying to use a sparse file to store sparse array of data, logically I thought the code had no bugs but the unit tests keep failing, after many inspections of code I decided to check the file content after every step and found out the holes were not created, aka: write first element, seek x amount of elements, write 2nd element ends up writing first element then second element in file without any space at all between them.

My simplified code:

    FILE* file = fopen64(fn.c_str(), "ar+b");
    auto const entryPoint = 220; //calculated at runtime, the size of each element is 220 bytes
    auto r = fseeko64(file, entryPoint, SEEK_SET);
    if(r!=0){
        std::cerr << "Error seeking file" << std::endl;
    }

    size_t written = fwrite(&page->entries[0], sizeof(page->entries), 1, file);
    if(written != 1) {
        perror("error writing file");
    }
    fclose(file);

The offset is being calculated correctly, current behavior is writing first element, leaving 20 elements empty then writing 22nd element. When inspecting file using hex dumps it shows 2 elements at offset 0 and 220 (directly after first element). unit tests also fail because reading 2nd element actually returns element number 22.

Anyone could explain what is wrong with my code? maybe I misunderstood the concept of holes???

------Edit1------

Here's my full code

Read function:

FILE* file = fopen64(fn.c_str(), "r+b");
if(file == nullptr){
    memset(page->entries, 0, sizeof(page->entries));
    return ;
}
MoveCursor(file, id, sizeof(page->entries));
size_t read = fread(&page->entries[0], sizeof(page->entries), 1, file);
fclose(file);
if(read != 1){ //didn't read a full page.
    memset(page->entries, 0, sizeof(page->entries));
}

Write function:

auto fn = dir.path().string() + std::filesystem::path::preferred_separator + GetFileId(page->pageId);
FILE* file = fopen64(fn.c_str(), "ar+b");
MoveCursor(file, page->pageId, sizeof(page->entries));
size_t written = fwrite(&page->entries[0], sizeof(page->entries), 1, file);
if(written != 1) {
    perror("error writing file");
}
fclose(file);


void MoveCursor(FILE* file, TPageId pid, size_t pageMultiplier){
    auto const entryPoint = pid * pageMultiplier;
    auto r = fseeko64(file, entryPoint, SEEK_SET);
    if(r!=0){
        std::cerr << "Error seeking file" << std::endl;
    }
}

And here's a simplified page class:

template<typename TPageId uint32_t EntriesCount>
struct PODPage {
    bool dirtyBit = false;
    TPageId pageId;
    uint32_t entries[EntriesCount];
};

The reason I'm saying it is fseeko problem when writing is because when inspecting file content with xdd it shows data is out of order. Break points in MoveCursor function shows the offset is calculated correctly and manual inspection of file fields shows the offset is set correctly however when writing it doesn't leave a hole.

=============Edit2============

Minimal reproducer, logic goes as: write first chunk of data, seek to position 900, write second chunk of data, then try to read from position 900 and compare to data that was supposed to be there. Each operation opens and closes file which is what happens in my original code, keeping a file open is not allowed. Expected behavior is to create a hole in file, actual behavior is the file is written sequentially without holes.

#include <iostream>
#define _FILE_OFFSET_BITS 64
#define __USE_FILE_OFFSET64 1

#include <stdio.h>
#include <cstring>

int main() {
    uint32_t data[10] = {1,2,3,4,5,6,7,8,9};
    uint32_t data2[10] = {9,8,7,6,5,4,3,2,1};
    {
        FILE* file = fopen64("data", "ar+b");
        if(fwrite(&data[0], sizeof(data), 1, file) !=1) {
            perror("err1");
            return 0;
        }
        fclose(file);
    }
    {
        FILE* file = fopen64("data", "ar+b");
        if (fseeko64(file, 900, SEEK_SET) != 0) {
            perror("err2");
            return 0;
        }
        if(fwrite(&data2[0], sizeof(data2), 1, file) !=1) {
            perror("err3");
            return 0;
        }
        fclose(file);
    }
    {
        FILE* file = fopen64("data", "r+b");
        if (fseeko64(file, 900, SEEK_SET) != 0) {
            perror("err4");
            return 0;
        }
        uint32_t data3[10] = {0};
        if(fread(&data3[0], sizeof(data3), 1, file)!=1) {
            perror("err5");
            return 0;
        }
        fclose(file);
        if (memcmp(&data2[0],&data3[0],sizeof(data))!=0) {
            std::cerr << "err6";
            return 0;
        }
    }
    return 0;
}

Answer 1

I think your problem is the same as discussed here:

• fseek does not work when file is opened in "a" (append) mode
• Does fseek() move the file pointer to the beginning of the file if it was opened in "a+b" mode?

Summary of the two above: If a file is opened for appending (using "a") then fseek only applies to the read position, not to the write position. The write position will always be at the end of the file.

You can fix this by opening the file with "w" or "w+" instead. Both worked for me with your minimal code example.