If you have only 1 file, what the chunker does is split it into 124kb-blocks, hashes each block, put these hashes into a list, hash that list, and this becomes the hash of the file.
When you request a file, you first request the hash list thanks to the “hash of the file” (the hash of the list, really), look what blocks you are missing, and request these missing blocks.
In a text file, if you change a character, it will only change this block as the chunker will still split the file at the same place. The client will request the new hash for the list, get sent the hash list and say “Oh, I already have most of them! I will only request the one I lack”. You are lucky and only request 124kb \O/.
But. If :
- you add or remove a character somewhere in the text file, the chunker will split the file at the same positions… up to that point, so this block all subsequent block will have different hash. It’s better than downloading everything, but worst than downloading only one block
- you compress the file, any change will likely change bits in every blocks of the compressed file. so you will have the retrieve the whole file.
because the “chunckage” happens on the compressed file (for now). To date, IPFS sees any file as a string of bytes, it doesn’t understand that it would be smarter to decompress the file and chunk wisely. if you compress and do any modification, it’s game over: you will have to dowload everything.
So my bad, the above sentence should be:
(Exception, for uncompressed text file where the modification is at the end, only the last block will be modified; or uncompressed text file where you just change characters (not deleting, not adding). But these are very specific cases.)