I made my own image tagging software, which is likely to be supported (for me, by me) as long as I care. It's probably not the right choice for most people. Anyone who wants to use mine is free to do so, but it's not well packaged. Undoubtedly missing features some people consider mandatory. It also makes some unconventional choices.

If anyone wants to try it I will answer email about it, and we can arrange to meet on IRC. There are several mode repos on the same github account (that are part of the same system).

Basic ideas:

Client/server model. Server in C, client in python.

Everything you do it kept forever. The only persistant metadata storage is a log of everything you've done.

Image files are never ever touched. They are identified by their hash. Anything messing with them will break this.

There's a fuse filesystem for searches, which you can use with whatever viewer you like. There's also a (crappy) web interface.

You can import raw files and see jpegs in the fuse fs/web client. (The embedded jpeg found in nearly all raw files.)

It's undefined in either case, because == is not a sequence point. (That is, the right side will yield the value C had before this statement, but the left side might not. Probably anyway, I'm not going to look it up.)

In the grand internet tradition of answering a loosely related question which is no use at all to the asker, I will say that the "smart kids" might use something like ZFS, which almost handles this for you. (Take snapshots, save delta streams on your USB stick. Requires the backup to be a ZFS copy, not just the same files.)

Useless right now at least. But I've been pretty happy with switching my storage to ZFS, even if the Linux version sucks. (I mostly don't use the Linux version.) I'd recommend it to anyone who doesn't mind a bit of transitional pain.

A sensible C coder might use vasprintf instead of the example in that manpage. The fact that all the standard library functions aren't great for all (or sometimes any) use cases is hardly unique to C.

My main computer doesn't run a browser. (It does run a virtual machine with a browser.)

I think this and not being reachable from the public internet is all the protection it needs. (It's also running Ubuntu, but I don't think that makes any noticable difference compared to some other modern choice.)

SMTP has no such restriction. (Not saying it's good exactly, but it doesn't have that particular problem.)

The unix mbox format has that problem though, but there are plenty of better options for mail storage. And there are no interoperability problems with switching, except with local software.

I'm pretty sure the Linux version of dump doesn't do any snapshoting. The FreeBSD version can do it because the FS supports snapshots, but ext3 does not. (Maybe it will do snapshots automatically if you have a setup that will support them, but the original problem is that this is not the case.)

On a decently configured modern system using a less than modern filesystem. Which isn't really the best kind of decent configuration for all situations.

Yes, I am saying that. There are options for:
DRAM ECC enable
DRAM MCE enable
Chip-Kill mode enable
DRAM ECC Redirection
DRAM background scrubber
L2 cache background scrubber
DCache backdround scrubber

The full specs of my board are GA-MA770-UD3 rev 2.0 with BIOS version "FA", Kingston valueram ECC memory, Athlon X2 BE-2400 CPU. So tech support could be right for the board you asked about, though probably not.

While it's certainly true that most consumer boards don't have BIOS support for ECC, my Gigabyte GA-MA-770-UD3 does, so gigabyte probably doesn't lie when they claim support on other boards. (But these options are not shown if you don't actually have ECC-memory, so you could easily fool yourself when you check for it.)

Also my slightly older ABit AN-M2HD supports ECC. Both boards were bought with ECC in mind, it's not all that common. But it's certainly possible to get.

I suspect they have a capacitor large enough to finish committing their buffers. At least they seem to see little performance degradation with write barriers, and do retain all the files they should when I pull the power while writing. (I didn't do a proper test, but it seems to work correctly, assuming your OS does.)

(And for the record, any OS that still thinks anything the HD acks is written is living in a dream world, it hasn't been true for 15 years on consumer disks.)