Tencent/tinker · error · TinkerRuntimeException
rewritePatchInfoFileWithLock fail
Error message
rewritePatchInfoFileWithLock fail
What it means
SharePatchInfo.rewritePatchInfoFileWithLock locks the info lock file and serializes the new patch info; any exception from locking or the rewrite is wrapped as TinkerRuntimeException("rewritePatchInfoFileWithLock fail", e). It is the write-side counterpart of error 213 and typically indicates storage or lock problems.
Source
Thrown at tinker-android/tinker-android-loader/src/main/java/com/tencent/tinker/loader/shareutil/SharePatchInfo.java:120
return patchInfo;
}
public static boolean rewritePatchInfoFileWithLock(File pathInfoFile, SharePatchInfo info, File lockFile) {
if (pathInfoFile == null || info == null || lockFile == null) {
return false;
}
File lockParentFile = lockFile.getParentFile();
if (!lockParentFile.exists()) {
lockParentFile.mkdirs();
}
boolean rewriteSuccess;
ShareFileLockHelper fileLock = null;
try {
fileLock = ShareFileLockHelper.getFileLock(lockFile);
rewriteSuccess = rewritePatchInfoFile(pathInfoFile, info);
} catch (Exception e) {
throw new TinkerRuntimeException("rewritePatchInfoFileWithLock fail", e);
} finally {
try {
if (fileLock != null) {
fileLock.close();
}
} catch (IOException e) {
ShareTinkerLog.i(TAG, "releaseInfoLock error", e);
}
}
return rewriteSuccess;
}
private static SharePatchInfo readAndCheckProperty(File pathInfoFile) {
boolean isReadPatchSuccessful = false;
int numAttempts = 0;
String oldVer = null;
String newVer = null;View on GitHub (pinned to 1b7ea02c23)
Solutions
- Check the chained cause: IOException from locking vs write failure.
- Verify free space and write permissions on the tinker info directory.
- Serialize patch operations to a single process.
- Clean the tinker directory / reinstall if the lock state is stuck, then reapply the patch.
- Catch TinkerRuntimeException and surface a retryable patch-apply failure.
Example fix
// before
SharePatchInfo.rewritePatchInfoFileWithLock(infoFile, info, lockFile);
// after
try {
SharePatchInfo.rewritePatchInfoFileWithLock(infoFile, info, lockFile);
} catch (TinkerRuntimeException e) {
ShareTinkerLog.e(TAG, "rewrite patch info fail, will retry on next apply", e);
} Defensive patterns
Strategy: retry
Validate before calling
File parent = pathInfoFile.getParentFile();
if (parent == null || (!parent.exists() && !parent.mkdirs()) || !parent.canWrite()) {
// cannot write info file: abort before locking
}
if (getFreeBytes(parent) < MIN_FREE_BYTES) {
// low storage: defer patch apply
} Try / catch
try {
SharePatchInfo.rewritePatchInfoFileWithLock(infoFile, info, lockFile);
} catch (TinkerRuntimeException e) {
// transient lock/disk issue: schedule patch apply retry on next launch
} Prevention
- Check free disk space before applying patches.
- Serialize patch apply to one process.
- Make patch apply idempotent and restartable so retries are safe.
When it happens
Trigger: Calling rewritePatchInfoFileWithLock(pathInfoFile, info, lockFile) when the lock cannot be acquired or writing/serializing the properties file throws (disk full, permissions, concurrent writer).
Common situations: Low storage during patch apply; multiple processes patching concurrently; lock file left held after a crash; info directory deleted underneath the operation.
Related errors
- readAndCheckPropertyWithLock fail
- Tinker Exception:FileLockHelper lock file failed: {}
- Tinker Exception:FileLockHelper lock file failed: {}
- patch ${type} extract failed (${message}).
- patch %s extract failed (%s).
AI-assisted analysis of Tencent/tinker@1b7ea02c23 (2026-08-14).
Data as JSON: /api/errors/71dfefdac83e23a6.
Report an issue: GitHub.