It might work! Yes, userland programs should not be reset using inodes. Yes, it certainly depends on any scheme used to track blocks by any file systems that implement this function. None of this is grounds for rejecting this proposal out of control.
Here's how it might work.
To illustrate, suppose we have an index that tracks blocks with an array of direct pointers to data blocks. Also, suppose the inode has an initial offset and an end-offset that apply to the first and last blocks, respectively, so you can have fewer than full blocks at both the beginning and the end of the file.
Now suppose you want to add data. It will be like this.
IF (new data will fit into unused space in first data block) write the new data to the beginning of the first data block update the starting-offset return success indication to caller try to allocate a new data block IF (block allocation failed) return failure indication to caller shift all existing data block pointers down by one write the ID of the newly-allocated data block into the first slot of the array write as much data as will fit into the second block (the old first block) write the rest of data into the newly-allocated data block, shifted to the end starting-offset := (data block size - length of data in first block) return success indication to caller
source share