dbd: add -i option to invalidate AppleDouble CNID hints

[rdmark]

When nested volumes leave behind stale CNID hints in AppleDouble files, dbd -f alone cannot fix them because cnid_add() still receives the stale hint. The new -i flag skips reading AD hints entirely, letting the database assign fresh CNIDs which are then written back to the AppleDouble files.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

🔥 Spectest (AFP 3.4) - Flamegraph (AFP_ASSERT active)

Commit: 75e1d6ea0f8ec9086c1bc16040d5791916aa4cc3
Profiling: On-CPU sampling @ 999 Hz, DWARF call-graph, x86_64
Build: debugoptimized (-O2 -g -fno-omit-frame-pointer)
Runtime: 66s, Stacks: 984, SVG size: 528K

🔥 Open interactive Flamegraph (SVG)

📥 Download from artifacts →

🔝 Top 10 leaf functions

Function	Samples
_raw_spin_unlock_irqrestore	311311311
[ld-musl-x86_64.so.1]	131131131
do_syscall_64	114114114
find_get_block_common	60060060
dircache_remove_children	43043043
srso_alias_safe_ret	34034034
memcmp	34034034
dircache_process_deferred_chain	24024024
__cond_resched	21021021
x64_sys_call	19019019

[andylemin]

This is useful, however I'm not convinced -f cannot fix them?

On rebuild Dbd -f will see that the CNID hint does not match the database, and the database wins, and the CNID ID from the DB is used overwriting the CNID hint.

If the DB has no entry it saves the CNID hint into the DB checking the unique constraint on the ID key.
So any secondary duplicate CNID hint will have a key collision at which point it falls back to generating a fresh ID.

Am I missing something?
I understand this might be related to the different vol's but the CNIDs are unique per vol, so after the vol's are separated the rebuild still should work?

Approving as I like the start fresh ability anyway, just want to confirm my understanding

[augmentcode]

🤖 Augment PR Summary

Summary: Adds a new -i flag to dbd to ignore CNID hints stored in AppleDouble metadata so stale hints (e.g., from nested volumes) don’t influence CNID rebuilds.
Changes: Updates CLI parsing/usage + manpage, introduces DBD_FLAGS_STRIP_AD, and adjusts CNID scanning to skip reading AppleDouble CNID hints and rewrite metadata with the database-assigned CNID.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 2 suggestions posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

bin/dbd/cmd_dbd_scanvol.c:649: With DBD_FLAGS_STRIP_AD set, check_cnid() skips the ad_open() probe that previously set adfile_ok=1 on AD_VERSION_EA files lacking meta EA, so the later overwrite path can treat ad_open(...RDWR) failures as fatal and return CNID_INVALID for those entries.

Severity: high

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}

[augmentcode]

bin/dbd/cmd_dbd_scanvol.c:650: Because -i forces ad_cnid to stay CNID_INVALID, the ad_cnid != db_cnid && adfile_ok == 0 overwrite path will execute for every existing AppleDouble file even when DBD_FLAGS_SCAN (-s) is set, which appears to violate the documented “read only / no filesystem modifications” behavior.

Severity: medium

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}

[rdmark]

this is fair feedback, I wrote this as a hypothetical measure for the scenario where an invalid CNID was stored as AD hint, but I only tested with "normal" CNID hint repair scenarios

let me bring this back to draft status and gather some evidence that the new logic is actually required

[andylemin]

this is fair feedback, I wrote this as a hypothetical measure for the scenario where an invalid CNID was stored as AD hint, but I only tested with "normal" CNID hint repair scenarios

let me bring this back to draft status and gather some evidence that the new logic is actually required

I still like this 😉 resetting all CNIDs is feel-good