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

  1. Check the chained cause: IOException from locking vs write failure.
  2. Verify free space and write permissions on the tinker info directory.
  3. Serialize patch operations to a single process.
  4. Clean the tinker directory / reinstall if the lock state is stuck, then reapply the patch.
  5. 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

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


AI-assisted analysis of Tencent/tinker@1b7ea02c23 (2026-08-14). Data as JSON: /api/errors/71dfefdac83e23a6. Report an issue: GitHub.