Skip to content

KnownFile hashing open failures log stale or wrong error text on Win32 open failure

Historical reference only: stale-v0.72a-experimental-clean and analysis\stale-v0.72a-experimental-clean are retired reference sources, not active branch targets or current baselines. Use them only as provenance or idea-extraction sources; landed status is determined against main. See Historical References.

Summary

Current main reports the wrong error details when a hash-open fails in CKnownFile.

CreateFromFile() and CreateAICHHashSetOnly() open files through the long-path Win32 helper OpenFileStreamSharedReadLongPath(), but on failure they format IDS_ERR_FILEOPEN with _tcserror(errno). That helper opens through CreateFile/_open_osfhandle/_fdopen, and a pure CreateFile failure does not populate a meaningful CRT errno value for the caller path being logged.

The result is a user-visible log/status message that can show stale or unrelated CRT text instead of the actual Windows open failure.

Landed In Main

Fixed in eMule-main by commit 897c207 (BUG-025 fix KnownFile hash-open Win32 diagnostics).

The landed fix:

  • captures GetLastError() immediately after hashing opens fail
  • logs IDS_ERR_FILEOPEN with the real Win32 reason via GetErrorMessage(dwError)
  • removes the stale _tcserror(errno) path in both CreateFromFile() and CreateAICHHashSetOnly()

Validated by supported app rebuild:

  • EMULE_WORKSPACE_ROOT\workspaces\v0.72a\state\build-logs\20260418-204138\summary.json

Evidence In Current Tree

  • srchybrid/KnownFile.cpp:405-409
  • CreateFromFile() logs:
  • LogError(GetResString(IDS_ERR_FILEOPEN) + _T(" - %s"), (LPCTSTR)strFilePath, _T(""), _tcserror(errno));
  • srchybrid/KnownFile.cpp:530-533
  • CreateAICHHashSetOnly() uses the same pattern
  • srchybrid/emule.rc:1960
  • IDS_ERR_FILEOPEN is already Failed to open %s (%s)
  • srchybrid/LongPathSeams.h:1245-1265
  • the long-path helper opens via CreateFile, _open_osfhandle, and _fdopen
  • srchybrid/LongPathSeams.h:1327-1331
  • OpenFileStreamSharedReadLongPath() is just the Win32/CRT bridge wrapper

Why This Is A Real Bug

When CreateFile fails with something like ERROR_SHARING_VIOLATION, current main does not preserve and format that Win32 error. Instead it asks the CRT for errno text after the helper has already returned NULL.

That produces misleading diagnostics on a live path used by automatic shared-file hashing and AICH recalculation. The bug is user-visible in logs/status output and makes support diagnosis harder because the reported reason may not match the real failure.

User-Visible Impact

  • file-open failures during hashing can show the wrong reason text
  • sharing/lock violations can be reported as unrelated CRT failures
  • the message format is also awkward because the resource already contains the %s (%s) structure and the current code appends an extra - %s

Cross-Variant Status

  • workspaces\v0.72a\app\eMule-main\srchybrid\KnownFile.cpp:407,532
  • bug is present
  • analysis\emuleai\srchybrid\KnownFile.cpp:75-99
  • CreateFromFile() is fixed there by capturing a Win32 error and formatting it through LogFileOpenFailure(...)
  • analysis\emuleai\srchybrid\KnownFile.cpp:561
  • CreateAICHHashSetOnly() still uses _tcserror(errno) there, so the fix is only partial in that tree
  • analysis\stale-v0.72a-experimental-clean\srchybrid\KnownFile.cpp:467,613
  • fixed there by using GetErrorMessage(::GetLastError())

Likely Fix Shape

Any acceptable fix should:

  1. capture the real Win32 open error from the failing helper path
  2. format IDS_ERR_FILEOPEN with (path, GetErrorMessage(dwError))
  3. remove the current + _T(" - %s") suffix and dummy empty-string argument

Optional follow-up:

  • adopt the short sharing/lock retry used by emuleai for startup hashing

Validation Target

  • force a sharing violation on a file being hashed
  • verify the log/status message reports the actual Windows reason
  • verify the output no longer shows stale or unrelated translated CRT text
  • verify both CreateFromFile() and CreateAICHHashSetOnly() use the same corrected error path