MuntashirAkon/AppManager · warning · UnsupportedOperationException
deleteOnExit() is not supported in RemoteFile
Error message
deleteOnExit() is not supported in RemoteFile
What it means
RemoteFile.deleteOnExit() unconditionally throws UnsupportedOperationException because delete-on-exit semantics require a JVM shutdown hook and an on-device File registry, which cannot be honored for files managed in a remote process. The library explicitly rejects the operation rather than silently ignoring it.
Solutions
- Replace deleteOnExit() with explicit delete() calls at a well-defined point in your flow.
- Track remote temp files in your own list and clean them up on shutdown/exit of your component.
- Guard generic cleanup code with instanceof checks so RemoteFile paths use explicit deletion.
- If using a File-agnostic helper, use tryDelete-style wrappers that skip unsupported operations.
Example fix
// before remoteFile.deleteOnExit(); // after runtime.addShutdownHook(new Thread(() -> remoteFile.delete()));
Defensive patterns
Strategy: fallback
Validate before calling
if (file instanceof RemoteFile) {
// use explicit delete(); deleteOnExit() is unsupported
} Type guard
boolean supportsDeleteOnExit(Object f) {
return !(f instanceof RemoteFile);
} Try / catch
try {
file.deleteOnExit();
} catch (UnsupportedOperationException e) {
cleanupRegistry.add(file); // explicit delete later
} Prevention
- Never assume java.io.File API parity on RemoteFile.
- Centralize temp-file cleanup so RemoteFile paths get explicit delete().
- Check the class javadoc for UnsupportedOperationException-declared methods before calling.
When it happens
Trigger: Calling deleteOnExit() on any RemoteFile instance — always throws, regardless of path or state.
Common situations: Porting code written against java.io.File to RemoteFile and assuming API parity; temp-file cleanup utilities that call deleteOnExit generically on File-like abstractions.
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
- Android System (android) cannot be backed up.
- Flags must be returned by the corresponding subclasses. key
- Invalid key
- Invalid key
- Invalid key
AI-assisted analysis of MuntashirAkon/AppManager@0152f468fc (2026-09-12).
Data as JSON: /api/errors/0030b5e0e27f9f69.
Report an issue: GitHub.
Appendix: source
Thrown at libcore/io/src/main/java/io/github/muntashirakon/io/RemoteFile.java:312
try {
return fs.createLink(getPath(), target, true).tryAndGet();
} catch (RemoteException e) {
throw new IOException(e);
}
}
@Override
public boolean delete() {
try {
return fs.delete(getPath());
} catch (RemoteException e) {
return false;
}
}
@Override
public void deleteOnExit() {
throw new UnsupportedOperationException("deleteOnExit() is not supported in RemoteFile");
}
@Override
public String[] list() {
try {
StringParceledListSlice list = fs.list(getPath());
return list != null ? list.getList().toArray(new String[0]) : null;
} catch (RemoteException e) {
return null;
}
}
@Override
public boolean mkdir() {
try {
return fs.mkdir(getPath());
} catch (RemoteException e) {
return false;View on GitHub (pinned to 0152f468fc)