GitLab

Previously if the remote safe directory wasn't fully created, the script
would crash and leave files in the remote processing directory

We have service docs that are way more extensive, meaningful and
relevant than keeping those historical details in the project's README
file.

Plus it would be silly to keep those things duplicated between the two
places...

Use os.path.join instead of string concatenation

See merge request !9

It seems like this was the result of a massive search and replace that
was a little too enthusiastic.

Any `docker run --tty` (which `-it` implies) crashes with:

    the input device is not a TTY

... when running as a systemd service. It seems like keeping
`-i` (which we expand to `--interactive` for clarity) keeps everything
normal (ie. we still see the container output).

Closes: #15

We need an extra control after argument passing to make sure it's
there when the options are not given though.

This is the proper place to this level of abstraction, i think.

This makes it possible to enable verbose without reloading systemd.

I'm not exactly sure we'll go that route, but it will make deployment
clearer.

Note that this involves renaming the main script, which makes the
directory listing a little more confusing and redundant, but it makes
the `setup.py` stuff easier (because we don't need to rename the
file).

The downside is that it doesn't look like a python module anymore,
which confuses some tools, but we can always add a symlink in the
source (like we do in undertime) to workaround that problem, in the
future.

Closes: #3

This hasn't actually been tested but, really, "how hard can this be?"

We're pretty good at avoiding race conditions (by moving stuff to
`dangerzone/processing`, mostly) but we definitely should avoid two
processors in parallel. Thankfully, it seems that systemd takes care
of this for us and will not run two services in parallel.

Obviously, the user can still shoot themselves in the foot and run
another processor in parallel, but that's when our race avoidance
stuff should save us.

Closes: #1

The `upload_sync()` function actually wipes the remote directory (or,
more precisely, removes files not present locally), so we actually
need to specify which component we need to upload, otherwise other
sanitized folders will get destroyed.

Closes: #7

handle already existing remote files on move

Closes #4

See merge request !3

hide all dangerous folders under a single dangerzone/ folder

Closes #4

See merge request !2

For some reason, we have files in the processing folder that are
already present before moving. Skip those files instead of crashing
with:

webdav3.exceptions.ResponseErrorCode: Request to https://nc.torproject.net/remote.php/dav/files/dangerzone-bot/CVS/dangerzone-processing/2/ failed with code 412 and message: b'<?xml version="1.0" encoding="utf-8"?>\n<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">\n  <s:exception>Sabre\\DAV\\Exception\\PreconditionFailed</s:exception>\n  <s:message>The destination node already exists, and the overwrite header is set to false</s:message>\n  <s:header>Overwrite</s:header>\n</d:error>\n'

Right now we have `dangerzene-processed/`, `dangerzone-rejected/`,
`dangerzone-processing/`... that's noisy, at best, and dangerous, at
worst: at least one user thought that `dangerzone-processed` was where
processed (so: safe) files ended up.

Just have `dangerzone/` and `safe/` folders at the toplevel, with the
`processed/`, `rejected/`, `processing/` stuff inside `dangerzone/`.

Closes: #4

fix incorrect SPECIAL_FOLDERS path check

Closes #8

See merge request !1

remove trailing slash from SPECIAL_FOLDERS entry
create function to normalize paths before checking to make things easier for
caller
closes #8

Not sure why that worked, but this can't hurt.

See: #6

Partly based on notes from
team#40256