MuntashirAkon/AppManager · error · UnsupportedOperationException
Locking a remote file is not supported!
Error message
Locking a remote file is not supported!
What it means
RemoteFileChannel extends FileChannel to wrap a remote file, but POSIX-style file locking cannot be implemented over the remote-file transport, so lock() unconditionally throws UnsupportedOperationException. The library deliberately rejects the operation instead of silently misbehaving. Any blocking lock attempt on a remote file channel fails immediately.
Solutions
- Remove the lock() call and use an application-level mutex/synchronization instead
- Restrict locking code paths to local files only (check the file type before locking)
- Use an alternative coordination mechanism such as a lock file on local storage
Example fix
// before
try (FileLock lck = channel.lock(0, Long.MAX_VALUE, false)) { ... }
// after
if (!(channel instanceof RemoteFileChannel)) {
try (FileLock lck = channel.lock(0, Long.MAX_VALUE, false)) { ... }
} else {
// app-level synchronization
} Defensive patterns
Strategy: try-catch
Validate before calling
boolean canLock = !(channel instanceof RemoteFileChannel);
Type guard
boolean isRemoteChannel(FileChannel ch) { return ch instanceof RemoteFileChannel; } Try / catch
try {
channel.lock(0, Long.MAX_VALUE, false);
} catch (UnsupportedOperationException e) {
// fall back to app-level synchronization
} Prevention
- Check the concrete channel/file type before using FileChannel features
- Never assume FileChannel subclasses support the full FileChannel API
- Use app-level locks for cross-process coordination on remote files
When it happens
Trigger: Calling FileChannel.lock(long,long,boolean) on a channel obtained for a remote file (e.g. via RemoteFile inputs), typically to coordinate exclusive access across processes.
Common situations: Code written for local files that uses lock() for atomic read-modify-write or to prevent concurrent modification, later run against a remote file path in App Manager's file abstraction.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
- Flags must be returned by the corresponding subclasses. key
- Invalid key
- Invalid key
- Invalid key
- Invalid key
AI-assisted analysis of MuntashirAkon/AppManager@0152f468fc (2026-09-12).
Data as JSON: /api/errors/d01393455b201fdd.
Report an issue: GitHub.
Appendix: source
Thrown at libcore/io/src/main/java/io/github/muntashirakon/io/RemoteFileChannel.java:361
@Override
protected void implCloseChannel() {
try { fs.close(handle); } catch (RemoteException ignored) {}
synchronized (fdLock) {
try { Os.close(read); } catch (ErrnoException ignored) {}
try { Os.close(write); } catch (ErrnoException ignored) {}
}
}
// Unsupported operations
@Override
public MappedByteBuffer map(MapMode mode, long position, long size) {
throw new UnsupportedOperationException("Memory mapping a remote file is not supported!");
}
@Override
public FileLock lock(long position, long size, boolean shared) {
throw new UnsupportedOperationException("Locking a remote file is not supported!");
}
@Override
public FileLock tryLock(long position, long size, boolean shared) {
throw new UnsupportedOperationException("Locking a remote file is not supported!");
}
}View on GitHub (pinned to 0152f468fc)