fix seek and write to block start zeros rest of block after written data (#188)

[yanshay]

Fix for #188 where seeking to offset of block size multiple and then writing, writes the data and zero the leftover of the block size instead of keeping the data that was there.
Includes also test for seek+write at both offset that worked and offset that didn't work.

[thejpster]

I think I would prefer something like:

            let block = if (block_offset == 0) && (to_copy == Block::LEN) {
                // we're replacing the whole Block, so the previous contents
                // are irrelevant
                data.block_cache.blank_mut(block_idx)
            } else {
                debug!("Reading for partial block write");
                data.block_cache
                    .read_mut(block_idx)
                    .map_err(Error::DeviceError)?
            };

This also passes your new test case.

[thejpster]

I believe that your fix would mean a write of 512 bytes at the start of the file would do a read-modify-write, when a write is sufficient.

[yanshay]

erased previously written command, got confused a bit.

What does to_copy end up being there?
bytes_to_write - written is the amount of total data left to write.
block_avail - is it the size of a available in the block starting the write point? so if block_offset is 0 it means it would be Block::LEN ?

[thejpster]

So I replied to your erased comment. Deleting my replies.

[yanshay]

I don't have any preference, not really very familiar with the code. Let me know your preference and I'll modify it, I trust your judgement better than mine here.

[thejpster]

to_copy is the amount of stuff we are writing to this block (see the slice copy that happens after). block_avail is how much stuff in this block (starting at the beginning of the block, because you cannot have holes in files when using FAT) is actually valid.

This might be better:

            let block = if (block_offset == 0) && (to_copy == block_avail) {
                // we're replacing the whole Block, so the previous contents
                // are irrelevant
                data.block_cache.blank_mut(block_idx)
            } else {
                debug!("Reading for partial block write");
                data.block_cache
                    .read_mut(block_idx)
                    .map_err(Error::DeviceError)?
            };

[thejpster]

Consider a file that is 1026 bytes long. We write 514 bytes starting at offset 511.

We should:

1. Read-modify-write Block 0 in the file, replacing block[511]
2. Write Block 1 in the file.
3. Read-modify write Block 2 in the file, replacing block[0] but leaving block[1] unchanged (and leaving block[2..512] unchanged as well).

Consider a file that is 1026 bytes long. We write 515 bytes starting at offset 511.

We should:

1. Read-modify-write Block 0 in the file, replacing block[511]
2. Write Block 1 in the file
3. Write Block 2 - it contains two data bytes at block[0..2] and 510 zero bytes after that, but the zeroes are beyond the EOF.

[yanshay]

I made the update based on the above and also updated the changelog.
Anything else required?

[thejpster]

Thank you!