Write support...

[t-w]

Plenty to fix (see also lclevy/ADFlib#30). I will put some notes on this here.

[t-w]

Probably have to start from putting diagnostics on everything possible - in many cases return status of the functions is not checked...

[t-w]

File (object) state management seems overcomplex, hard to debug and make robust:

• current code assumes that there is always ready to use read/write buffer (block)
  • the first problem - there is no data block if the file size is 0...
  • what if reading/writing a block fails? (currently in many places not checked!)
  • currently no way to invalidate current data pointer (eg. after invalid reading next block)
  • it may (eventually) be better to separate data buffering
  • manage properly buffer state ie. whether a block/buffer is modified and has to be written back
• some things kept as state information of the opened file are redundant (ie. things trivially calculated from others)
  • eg. posInDataBlk - to calculate from pos
  • what important - it is difficult to keep them all in a consistent state, better store minimal/required set and calculate other things where/when needed (locally - such computations are nothing vs i/o...)

But... if there will be no reasonable way to untangle and simplify it, it may be necessary to redesign and rewrite the whole adf_file module...

[t-w]

File size in file header in set only in adfFlushFile in the following way:

  file->fileHdr->byteSize = file->pos;

meaning:

1. it is inconsistent while writing data
2. when writing something inside a file, the size will shrink to the last position after writing(!)

[t-w]

Invalidating current data block buffer (.currentData in struct adfFile) seems best to be done by setting .curDataPtr to 0 (no data block can be stored in sector/block 0). Otherwise eg. a new var. will have to be introduced (but this increases amount of things to keep consistent as state...).

[t-w]

Should seek operations read/write data?

• currently is does read but
  • it is buggy (ie. for 0 - length file there is no data block to read!)
• it is not writing current (possibly changed) block - what make impossible seeking file being written (results in data loss/corruption)
• seeking when writing should (like eg. in POSIX ?) write empty (zeroed) blocks when going over the size of the file

If seek will not read/write data:

• for OFS - data blocks must be read anyway (maybe should be to in a separated buffer?)

If going for the second (dropping any data operations when seeking):

• dropping read/write in seek and disallowing seek above length of the file will greatly simplify the lib. code +- in write mode, if seeking after modifying a data buffer, the data buffer will have to be flushed in another part of code which will need to use the data block buffer (read/write/close)

To decide... (dropping data ops seems simpler -> more robust -> better?).

[t-w]

So, after a few approaches decided to go back to what was there. Mentioned above things (dropping data operation when seeking etc. would require deep redesign (maybe even rewriting most) of the file api module. So in the end - keeping original way - current datablock always in the buffer (unless no data - an empty file)

Maybe some future revision or a fork/rewrite will change this. For now - it works well enough.

[t-w]

One thing is missing - seeking while writing (after a write operation) should write current buffer (can be modified). The trouble is that there is no info whether the buffer was modified... Just adding writing the buffer would write on every seek operation (in write mode)... No sure what to do with it, yet...

(but to implement somehow - with a test).

[t-w]

Volume filesystem write support was completed for 0.8.0.

The remaining thing, updating block allocation bitmap, was added recently (lclevy#64).