)]}'
{
  "commit": "488e84bb538c20a62b2976e9d631f81bf3fc51ec",
  "tree": "b7631b9e52633fc54446b16a82770f2eee67911e",
  "parents": [
    "adad0fbbcf5382c20978d07f94f9c13be9041c1b"
  ],
  "author": {
    "name": "Christopher Haster",
    "email": "geky@geky.net",
    "time": "Mon Mar 09 17:59:58 2026 -0500"
  },
  "committer": {
    "name": "Christopher Haster",
    "email": "geky@geky.net",
    "time": "Mon Mar 09 19:13:43 2026 -0500"
  },
  "message": "Fixed data corruption with multiple write handles\n\nMultiple write handles in littlefs has always been a bit confusing\n(hopefully improving in littlefs3), but I didn\u0027t realize it could lead\nto corrupted data.\n\nThe problem, as noted by Ictogan1, is that syncs to related file handles\nignores the LFS_F_DIRTY flag. If you open a file twice, and write to one\nhandle, littlefs doesn\u0027t realize the other handle it out-of-date.\n\nThis may not seem like a problem, but then littlefs is happy to\nreallocate those (still referenced) blocks, leading to data corruption:\n\n  open(a, \"quiche.txt\")\n  write(a)\n  sync(a) // syncs a\u0027s contents\n  open(b, \"quiche.txt\")\n  truncate(b)\n  sync(b) // syncs b\u0027s contents\n  write(b) // may allocate from a\n  rewind(a)\n  read(a) // potentially corrupted\n\n---\n\nWhat we want is to set LFS_F_DIRTY in all other file handles during\nlfs_file_sync, but doing so would force those file handles to sync\nduring close. That would be even more confusing (not to mention\nbackwards incompatible).\n\nIn theory setting both LFS_F_DIRTY + LFS_F_ERRED could work, but that\nwould prevent implicit syncs of writes that haven\u0027t actually errored:\n\n  open(a, \"quiche.txt\")\n  write(a)\n  open(b, \"quiche.txt\")\n  write(b)\n  close(b) // syncs b\u0027s contents\n  close(a) // should sync a\u0027s contents\n\nSo, instead, as a somewhat clunky workaround, a new flag: LFS_F_DUSTY,\nwhich indicates a file does not match storage, but should not be synced\nduring close.\n\n---\n\nIt\u0027s worth noting this is already fixed in littlefs3, which includes a\nmore rigorous, and hopefully easier to use sync model. But in the\nmeantime, this should at least prevent the loss of data.\n\nAdded test_alloc_multihandle and test_alloc_multihandle_reuse to prevent\na regression, test_alloc_multihandle_reuse does reproduce the bug.\n\nFound and reproduced by Ictogan1\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "da4bfca40066012de1a6e83bb95cde8d7f7e08b2",
      "old_mode": 33188,
      "old_path": "lfs.c",
      "new_id": "78eab28d8efa5c98d4fa16d9e1adf9748bf8d1bd",
      "new_mode": 33188,
      "new_path": "lfs.c"
    },
    {
      "type": "modify",
      "old_id": "215309c583c1eb38098c6cf08b6d2fc02cc0b6f1",
      "old_mode": 33188,
      "old_path": "lfs.h",
      "new_id": "8fbd5b479a848bd5001e18891d58061c3b43c858",
      "new_mode": 33188,
      "new_path": "lfs.h"
    },
    {
      "type": "modify",
      "old_id": "338c75d58ca2fa64ab617ef6c6d8c6adfbe814dd",
      "old_mode": 33188,
      "old_path": "tests/test_alloc.toml",
      "new_id": "7165f8fd2916b8942f210d3eafca9475c66225d9",
      "new_mode": 33188,
      "new_path": "tests/test_alloc.toml"
    }
  ]
}