ytdl-org/youtube-dl · warning · Exception

Not removing directory %s - this does not look like a cache

Error message

Not removing directory %s - this does not look like a cache dir

What it means

Raised on Windows when UnlockFileEx fails during release of a byte-range file lock previously taken by LockFileEx in youtube-dl's locked_file machinery. Like the locking error, the %r payload is the formatted Windows error. Failing to unlock is rarer than failing to lock and usually means the handle or lock state changed between acquisition and release (or the file was closed/mapped underneath the process).

Source

Thrown at youtube_dl/cache.py:138

            except (OSError, IOError) as oe:
                file_size = error_to_compat_str(oe)
            self._report_warning('Cache retrieval from %s failed (%s)' % (cache_fn, file_size))
        except Exception as e:
            if getattr(e, 'errno') == errno.ENOENT:
                # no cache available
                return
            self._report_warning('Cache retrieval from %s failed' % (cache_fn,))

        return default

    def remove(self):
        if not self.enabled:
            self._to_screen('Cache is disabled (Did you combine --no-cache-dir and --rm-cache-dir?)')
            return

        cachedir = self._get_root_dir()
        if not any((term in cachedir) for term in ('cache', 'tmp')):
            raise Exception('Not removing directory %s - this does not look like a cache dir' % (cachedir,))

        self._to_screen(
            'Removing cache dir %s .' % (cachedir,), skip_eol=True, ),
        if os.path.exists(cachedir):
            self._to_screen('.', skip_eol=True)
            shutil.rmtree(cachedir)
        self._to_screen('.')

View on GitHub (pinned to 956b8c5855)

Solutions

Treat an unlock failure as non-fatal: the lock disappears anyway when the handle closes/process exits, so log and continue instead of aborting a completed download.
Exclude the download directory from antivirus/sync tools so the file is not removed while locked.
Retry the whole download; a fresh run re-locks cleanly (the .part resume logic handles it).
Update youtube-dl / switch to yt-dlp — the locked_file usage and .part handling have been reworked.

Example fix

# before
with locked_file(path, 'a') as lf:  # unlock failure aborts run
    ...

# after
with locked_file(path, 'a') as lf:
    ...
# wrap release failures: patch or catch at the outer level
try:
    ...  # locked region
finally:
    try:
        pass  # __exit__ unlock
    except OSError:
        import logging; logging.warning('unlock failed; lock dies with handle')

Defensive patterns

Strategy: try-catch

Try / catch

try:
    with locked_file(path, 'a') as f:
        process(f)
except OSError as e:
    if 'Unlocking file failed' in str(e):
        pass  # data already written; the OS releases the lock when the handle closes
    else:
        raise

Prevention

Treat unlock failures as warnings — the byte-range lock dies with the handle anyway.
Never reopen or duplicate the file between lock and unlock; youtube-dl pins the OVERLAPPED struct on the file object.
Exclude download dirs from antivirus/sync tools that delete or rename locked files mid-run.

When it happens

Trigger: The file object's OS handle became invalid before __exit__ (console closed, file deleted by external software, handle reused); mixing lock/unlock across duplicated or reopened file objects — youtube-dl pins the OVERLAPPED struct on f._lock_file_overlapped_p, and losing that pairing (e.g. by reopening the file) breaks UnlockFileEx; SMB state resets dropping locks server-side.

Common situations: Antivirus or sync tools (OneDrive/Dropbox) deleting or renaming the .part file mid-download; processes being forcefully terminated between lock and unlock; network drives resetting sessions. Almost always environmental rather than a youtube-dl logic bug.

Related errors

AI-assisted analysis of ytdl-org/youtube-dl@956b8c5855 (2026-08-14). Data as JSON: /api/errors/79f15035feb83ccb. Report an issue: GitHub.