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

  1. Ensure external storage is available (check Environment.getExternalStorageState) before relying on the external path.
  2. Free internal storage space — a full internal partition can cause mkdir to fail.
  3. Clear the app's data/cache to reset the files directory to a known-good state.
  4. 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

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


AI-assisted analysis of TeamNewPipe/NewPipe@9e8be09156 (2026-08-14). Data as JSON: /api/errors/adba754899edfa30. Report an issue: GitHub.