statUTC(HANDLE) returns corrupted `st_size` by combining file size high with file index low
Historical reference only:
stale-v0.72a-experimental-cleanandanalysis\stale-v0.72a-experimental-cleanare retired reference sources, not active branch targets or current baselines. Use them only as provenance or idea-extraction sources; landed status is determined againstmain. See Historical References.
Summary¶
The HANDLE overload of statUTC is computing st_size from the wrong
BY_HANDLE_FILE_INFORMATION field.
Instead of combining nFileSizeHigh with nFileSizeLow, current main uses
nFileIndexLow. That means the returned size is corrupted for any caller that
reads st.st_size from the handle-based overload.
Landed In Main¶
Fixed in eMule-main by commit f33f38b (BUG-024 fix statUTC HANDLE size field).
The landed fix:
- replaces
fi.nFileIndexLowwithfi.nFileSizeLowin the handle-basedstatUTCoverload - makes the handle-based size calculation match the already-correct path-based overload
Validated by supported app rebuild:
EMULE_WORKSPACE_ROOT\workspaces\v0.72a\state\build-logs\20260418-204438\summary.json
Evidence In Current Tree¶
srchybrid/OtherFunctions.cpp:3205-3214statUTC(HANDLE hFile, struct _stat64 &ft)sets:ft.st_size = ((__int64)fi.nFileSizeHigh << 32) | fi.nFileIndexLow;srchybrid/OtherFunctions.cpp:3191-3202- the adjacent path-based overload uses the correct low dword:
fa.nFileSizeLow
Current Callers¶
Live main callers of the handle overload include:
srchybrid/KnownFile.cpp:511srchybrid/PartFile.cpp:1161srchybrid/OtherFunctions.cpp:1180srchybrid/Preview.cpp:211
The currently audited callers mostly consume timestamps, which limits the immediate visible fallout, but the utility contract is still wrong and any size-reading caller will receive corrupted data.
User-Visible / Runtime Impact¶
- inconsistent behavior between the path-based and handle-based
statUTCoverloads for the same file - latent wrong-file-size behavior for any present or future handle caller that
relies on
st.st_size - harder debugging because the struct contents look superficially valid while containing unrelated file-index bits
Cross-Variant Status¶
workspaces\v0.72a\app\eMule-main\srchybrid\OtherFunctions.cpp:3213- bug is present
analysis\stale-v0.72a-experimental-clean\srchybrid\OtherFunctions.cpp:2774- bug is also present there
analysis\emuleai\srchybrid\OtherFunctions.cpp:3075- fixed there; the code uses
fi.nFileSizeLow
Likely Fix Shape¶
Replace fi.nFileIndexLow with fi.nFileSizeLow in the handle overload.
Because the path overload already has the correct logic, this should be a one-line correctness fix plus a targeted regression check if a seam/unit test is available for the helper.
Validation Target¶
- call both
statUTC(path, st)andstatUTC(handle, st)for the same file - verify
st_size,st_mtime, andst_ctimematch - include a file larger than 4 GiB if a regression harness exists for that seam