# Remove a source file from the content directory

The opposite of the upload: the file ?file= names, exactly as the listing spells it,
is removed. Nothing else goes with it — no job record, stored rows or thumbnail, an
emptied subdirectory stays, and a symbolic link is removed as the link, never what it
points at.

Files are not owned by jobs. A finished job keeps its record and results without its
source; a failed or cancelled job on a removed file can no longer be resumed — the
resume answers 409 saying the source cannot be resolved, and automatic resume stands
down. 409 while a queued or running job is using the file, naming the job: cancel it
first, then delete. 404 when no such file is there. 400 for no name, an absolute or
escaping path, or a non-analyzable extension — the content directory is the Engine's
playback directory, and this removes only what the listing could show.

Endpoint: DELETE /vod/files
Version: 2.0.0
Security: engineBasic

## Query parameters:

  - `file` (string, required)
    The file to remove, relative to the content directory, as the listing names it.

## Response 400 fields (application/problem+json):

  - `type` (string)
    URI identifying the problem type.

  - `title` (string, required)
    Short, human-readable summary of the problem type.

  - `status` (integer, required)
    The HTTP status code, repeated from the response line.

  - `detail` (string)
    Human-readable explanation specific to this occurrence.

  - `instance` (string)
    URI identifying this specific occurrence of the problem.

## Response 404 fields (application/problem+json):

  - `type` (string)
    URI identifying the problem type.

  - `title` (string, required)
    Short, human-readable summary of the problem type.

  - `status` (integer, required)
    The HTTP status code, repeated from the response line.

  - `detail` (string)
    Human-readable explanation specific to this occurrence.

  - `instance` (string)
    URI identifying this specific occurrence of the problem.

## Response 409 fields (application/problem+json):

  - `type` (string)
    URI identifying the problem type.

  - `title` (string, required)
    Short, human-readable summary of the problem type.

  - `status` (integer, required)
    The HTTP status code, repeated from the response line.

  - `detail` (string)
    Human-readable explanation specific to this occurrence.

  - `instance` (string)
    URI identifying this specific occurrence of the problem.

## Response 503 fields (application/problem+json):

  - `type` (string)
    URI identifying the problem type.

  - `title` (string, required)
    Short, human-readable summary of the problem type.

  - `status` (integer, required)
    The HTTP status code, repeated from the response line.

  - `detail` (string)
    Human-readable explanation specific to this occurrence.

  - `instance` (string)
    URI identifying this specific occurrence of the problem.

## Response default fields (application/problem+json):

  - `type` (string)
    URI identifying the problem type.

  - `title` (string, required)
    Short, human-readable summary of the problem type.

  - `status` (integer, required)
    The HTTP status code, repeated from the response line.

  - `detail` (string)
    Human-readable explanation specific to this occurrence.

  - `instance` (string)
    URI identifying this specific occurrence of the problem.


## Response 204 fields