Re: Most simple filesystem with content checksums?

["Malcolm Herbert" <netbsd.org%mjch.net@localhost>]

Given we are in a NetBSD context, can I suggest you take a look at mtree?  If you have a NetBSD system running, have a look at the content of /etc/mtree where the system specs are and you can see how it works to enforce sane defaults when installing a system.

For your use you can tell mtree to create a specification file of the content of a directory tree and have it record a variety of details, including user/group and file permission details but also various checksum digests. For example (assuming bash):

$ mtree -c -p /some/path -K sha256 | tee path_spec.mtree

Once recorded, you can re-run mtree over the same directory tree at some later point and have it identify differences in the spec ... mtree will then either report these or attempt to fix them if it can.

I would caution that I have found mtree a little too eager to make filesystem changes, so for important data I'd recommend only using it to create the specification and comparing those yourself.  For ease of use, I'd suggest using the mtree -C format to compare them in, as this places the full path of the file at the beginning of each line, then you can compare their SHA256 checksums like so (assuming a bash shell):

$ diff -u <(
  mtree -C -f old_path_spec.mtree -R all -K sha256
) <(
  mtree -C -f new_path_spec.mtree -R all -K sha256
)

Regards,
Malcolm

On Sun, 25 Oct 2026, at 05:10, Ellie wrote:
> On 10/24/26 7:18 PM, Ben Collver wrote:
>> On Sat, Oct 24, 2026 at 06:30:45PM +0200, Ellie wrote:
>>> I wonder if there have ever been any considerations to add a content
>>> checksum capability (as an option, not as a requirement) to FFS, for
>>> example?
>> 
>> I do it at the application level using a short Tcl script recording
>> MD5 hashes of the files.  It's a manual process.  One benefit is that
>> it is filesystem agnostic.  I could use it on FAT if i wished.
>> 
> Thank you for sharing this!
>
> I have considered such a manual approach. What I'm concerned about 
> however, is that I would too often need to check if a change was 
> intentional and might get used to just pressing "yes" without being 
> actually sure if something was meant to change.
>
> So I'm not sure if that would be the most feasible for me. But how 
> interesting that I'm not the only one who thought about that approach!
>
> Regards,
>
> Ellie

-- 
Malcolm Herbert
mjch%mjch.net@localhost