external: normalize unambiguous file id lookup

[cheese-cakee]

Why this PR is necessary

external_lookup_id() used strict string comparison, so logically identical file[mnt_id:inode] IDs could fail to
match when represented differently.

What this PR changes

• Adds numeric normalization for file[mnt_id:inode] lookup in criu/external.c, with strict compatibility guards.
• Keeps exact strcmp() match as the first path.
• Applies normalization only when both components are unambiguous:
• 0x... => hex
• contains a-f/A-F => hex
• digits-only => ambiguous, no normalization
• Prevents ambiguous cross-matching (e.g. 11 vs 17) for backward compatibility.

Scope

• Single logical change in criu/external.c only.

Testing

• git diff --check HEAD~1..HEAD
• python3 -m py_compile test/zdtm.py test/zdtm/criu_config.py

[Copilot]

Pull request overview

This PR aims to make external regular-file id matching more robust across equivalent numeric representations (decimal vs hex) and improve restore diagnostics when CRIU falls back from --inherit-fd to path-based reopen.

Changes:

• Add normalization logic for file[mnt_id:inode] matching in external id lookup (keeping exact string compare as a fast path).
• Emit a warning during restore when an external file has no --inherit-fd mapping and CRIU falls back to reopening by path.
• Update CLI help and documentation to describe accepted numeric formats for file[mnt_id:inode].

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 5 comments.

File	Description
criu/files-reg.c	Adds a warning when --inherit-fd mapping is missing for an external file.
criu/external.c	Introduces parsing/normalization for file[mnt_id:inode] during external id lookup.
criu/crtools.c	Updates --external / --inherit-fd help text for file[mnt_id:inode] formats.
Documentation/criu.txt	Clarifies documentation for --external file[mnt_id:inode] numeric formats.

[cheese-cakee]

please review when possible @avagin

[codecov-commenter]

Codecov Report

❌ Patch coverage is 93.75000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 57.26%. Comparing base (b7f6b72) to head (aeba1ac).
⚠️ Report is 736 commits behind head on criu-dev.

Files with missing lines	Patch %	Lines
criu/external.c	93.75%	3 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           criu-dev    #2992      +/-   ##
============================================
- Coverage     57.76%   57.26%   -0.51%     
============================================
  Files           142      154      +12     
  Lines         37664    40486    +2822     
  Branches          0     8874    +8874     
============================================
+ Hits          21758    23185    +1427     
- Misses        15906    17037    +1131     
- Partials          0      264     +264     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[avagin]

@cheese-cakee please update the commit message with more details.

[avagin]

I get the goal here, but we need to be careful. Since the file[hex:hex] format lacks the 0x prefix, any hex value consisting only of numbers could be parsed as a decimal either...

[cheese-cakee]

I get the goal here, but we need to be careful. Since the file[hex:hex] format lacks the 0x prefix, any hex value consisting only of numbers could be parsed as a decimal either...

I addressed this by making CRIU emit the 0x prefix (changed the snprintf in dump_one_reg_file from %x to 0x%x), so the format is unambiguous going forward. The parser now requires 0x for hex

[avagin]

I get the goal here, but we need to be careful. Since the file[hex:hex] format lacks the 0x prefix, any hex value consisting only of numbers could be parsed as a decimal either...

I addressed this by making CRIU emit the 0x prefix (changed the snprintf in dump_one_reg_file from %x to 0x%x), so the format is unambiguous going forward. The parser now requires 0x for hex

I don't understand how it will help us. We can't break existing users, so we need to proper handle the old format...

[rst0git]

Adding a note that I believe this is also related to the comments in #2951 (comment) and #2973

[rst0git]

I believe this is the breaking change that Andrei is referring to. There is no reliable way for us to parse decimal numbers here. For example, 0x11 == 17. When 0x is removed, we have no way of knowing if the input is 11 or 17.

[cheese-cakee]

I'll drop the emission change and instead make the parser try decimal first (matching user expectation for --inherit-fd arguments) and fall back to hex only when the decimal parse fails

[avagin]

again, it can break backward compatibility. Please explain in the commit message in details why existing users will be not affected by this change. Try to think on a case when there are two external resources with ids '11' and '17'.

[cheese-cakee]

Now normalization is applied only when both components (mnt_id and inode) are unambiguous:

• 0x... => unambiguous hex
• contains a-f/A-F => unambiguous hex
• digits-only => ambiguous, no normalization

So file[11:17] and file[17:23] keep literal/exact semantics and won’t be cross-matched by numeric normalization.
external_lookup_id() still does exact strcmp() first, then numeric compare only for unambiguous IDs

[rst0git]

@cheese-cakee Were you able to test these changes? It sounds overcomplicated, and I am not sure the logic is correct. Note that AI chatbots can make mistakes.

[cheese-cakee]

I have tested the new changes and I have tried to simplify the implementation :
Normalization only when both mnt_id AND inode are unambiguous:

• 0x... or contains a-f → hex
• digits-only (like 11) → treated as decimal, no normalization

please review if its alright