<p>The second is correct. The <code>blk*.dat</code> files are append only. Once a block is downloaded and written to disk, it is never deleted (except when pruning). A block index (database) is maintained in <code>blocks/index</code> to keep track of block locations on disk and statuses (valid, invalid, etc.).</p>

CC BY-SA 4.0
2019-01-24T04:07:32.093Z
2019-01-24T04:07:32.093Z
Ava Chow
<p>I’m interested in writing a program that will (1) parse the .blk files that my full-node Bitcoin daemon writes to disk and (2) write them to a relational database in an incremental fashion (i.e., keeping tracking of which .blk files I’ve already seen to avoid duplicating work). But it seems that this approach could lead to problems when my Bitcoin daemon says “uh-oh, another chain is bigger than the chain we currently have, let’s switch to it.” Specifically, I could imagine two possibilities:</p>

<ol>
<li><p>The Bitcoin daemon goes back into an existing .blk file and deletes the blocks from the old chain. If that’s what happens, my program would need to keep track of the mtime of the .blk files on disk and overwrite the parsed data that was sourced from those .blk files when the mtime changes.</p></li>
<li><p>The Bitcoin daemon never modifies “finished” .blk files (i.e., block files other than the latest one that’s currently being written to), but rather knows that some of the blocks inside the .blk files could correspond to rejected blockchains. If this is the case, my program would need to query the daemon for this information and update the destination database appropriately.</p></li>
</ol>

<p>Which (if either) of those possibilities is correct?</p>

<bitcoind><nodes><full-node>
What happens to .blk files on disk when the Bitcoin daemon switches to a longer chain?
Aaron Rubin
# What happens to .blk files on disk when the Bitcoin daemon switches to a longer chain?

(Asked by: username_0 on 2019-01-24)

I’m interested in writing a program that will (1) parse the .blk files that my full-node Bitcoin daemon writes to disk and (2) write them to a relational database in an incremental fashion (i.e., keeping tracking of which .blk files I’ve already seen to avoid duplicating work). But it seems that this approach could lead to problems when my Bitcoin daemon says “uh-oh, another chain is bigger than the chain we currently have, let’s switch to it.” Specifically, I could imagine two possibilities:

1. The Bitcoin daemon goes back into an existing .blk file and deletes the blocks from the old chain. If that’s what happens, my program would need to keep track of the mtime of the .blk files on disk and overwrite the parsed data that was sourced from those .blk files when the mtime changes.
2. The Bitcoin daemon never modifies “finished” .blk files (i.e., block files other than the latest one that’s currently being written to), but rather knows that some of the blocks inside the .blk files could correspond to rejected blockchains. If this is the case, my program would need to query the daemon for this information and update the destination database appropriately.

Which (if either) of those possibilities is correct?

**Tags:** bitcoind, nodes, full-node


---

## 1 answers

### Answer by username_1 on 2019-01-24. Score: 2 | Accepted answer

The second is correct. The `blk*.dat` files are append only. Once a block is downloaded and written to disk, it is never deleted (except when pruning). A block index (database) is maintained in `blocks/index` to keep track of block locations on disk and statuses (valid, invalid, etc.).


---

