TeamNewPipe/NewPipe · critical · RuntimeException
path to pending downloads are not accessible
Error message
path to pending downloads are not accessible
What it means
Thrown by DownloadManager.getPendingDir when neither candidate directory for pending-download metadata passes the testDir() check. The method first tries the app's external files dir (getExternalFilesDir(DOWNLOADS_METADATA_FOLDER)), then falls back to internal files dir (getFilesDir() + DOWNLOADS_METADATA_FOLDER); if both fail testDir (null, or Utility.mkdir cannot create/write it), it throws a RuntimeException. This is a fatal init failure: the download manager cannot function without a writable metadata directory.
Source
Thrown at app/src/main/java/us/shandian/giga/service/DownloadManager.java:89
mFinishedMissionStore = new FinishedMissionStore(context);
mHandler = handler;
mMainStorageAudio = storageAudio;
mMainStorageVideo = storageVideo;
mMissionsFinished = loadFinishedMissions();
mPendingMissionsDir = getPendingDir(context);
loadPendingMissions(context);
}
private static File getPendingDir(@NonNull Context context) {
File dir = context.getExternalFilesDir(DOWNLOADS_METADATA_FOLDER);
if (testDir(dir)) return dir;
dir = new File(context.getFilesDir(), DOWNLOADS_METADATA_FOLDER);
if (testDir(dir)) return dir;
throw new RuntimeException("path to pending downloads are not accessible");
}
private static boolean testDir(@Nullable File dir) {
if (dir == null) return false;
try {
if (!Utility.mkdir(dir, false)) {
Log.e(TAG, "testDir() cannot create the directory in path: " + dir.getAbsolutePath());
return false;
}
File tmp = new File(dir, ".tmp");
if (!tmp.createNewFile()) return false;
return tmp.delete();// if the file was created, SHOULD BE deleted too
} catch (Exception e) {
Log.e(TAG, "testDir() failed: " + dir.getAbsolutePath(), e);
return false;
}View on GitHub (pinned to 9e8be09156)
Solutions
- Ensure external storage is available (check Environment.getExternalStorageState) before relying on the external path.
- Free internal storage space — a full internal partition can cause mkdir to fail.
- Clear the app's data/cache to reset the files directory to a known-good state.
- If reproducible on a specific ROM/device, report the getExternalFilesDir-null behavior and add a third fallback (context.getCacheDir) as a last resort.
Example fix
// before
File dir = new File(context.getFilesDir(), DOWNLOADS_METADATA_FOLDER);
if (testDir(dir)) return dir;
thrown new RuntimeException("path to pending downloads are not accessible");
// after — add cache dir as last-resort fallback
File dir = new File(context.getFilesDir(), DOWNLOADS_METADATA_FOLDER);
if (testDir(dir)) return dir;
dir = new File(context.getCacheDir(), DOWNLOADS_METADATA_FOLDER);
if (testDir(dir)) return dir;
throw new RuntimeException("path to pending downloads are not accessible"); Defensive patterns
Strategy: try-catch
Validate before calling
// Before constructing DownloadManager, verify at least one metadata dir is usable:
File ext = context.getExternalFilesDir(DOWNLOADS_METADATA_FOLDER);
if (ext == null || !ext.exists() && !ext.mkdirs()) {
File internal = new File(context.getFilesDir(), DOWNLOADS_METADATA_FOLDER);
if (!internal.exists() && !internal.mkdirs()) {
// warn user: downloads cannot persist on this device state
}
} Try / catch
try {
DownloadManager dm = new DownloadManager(context);
} catch (RuntimeException e) {
if (e.getMessage() != null && e.getMessage().contains("path to pending downloads")) {
// fatal init — notify user that storage is inaccessible
showStorageErrorDialog();
} else throw e;
} Prevention
- Check Environment.getExternalStorageState() before relying on external paths.
- Free internal storage space to avoid mkdir failures.
- Clear app data if the files directory is in a corrupt state.
- Add a cache-dir fallback in getPendingDir as a last resort.
When it happens
Trigger: getPendingDir(context) returns from both branches without a passing dir: getExternalFilesDir returns null (no external storage mounted), and the internal getFilesDir path also fails testDir (Utility.mkdir returns false — rare, indicates filesystem/permission failure on internal storage). The throw at line 89 fires.
Common situations: Device with no external storage and a ROM where getExternalFilesDir returns null; internal storage in an error state (disk full, filesystem corruption); a custom ROM permission bug blocking internal dir creation; the app's data directory was partially cleared/corrupted leaving getFilesDir in a bad state.
Related errors
- Cache dir does not exist >
- No write permissions on {}
- Failed to create the tree from Uri
- Cannot create the file
- SAF not available
AI-assisted analysis of TeamNewPipe/NewPipe@9e8be09156 (2026-08-14).
Data as JSON: /api/errors/adba754899edfa30.
Report an issue: GitHub.