Refers to #5

Fixes #5

Refers to #5

Fixes #36

Refers to #36

Refers to #36

Refers to #36

Refers to #36

Refers to #36

Refers to #36

Refers to #3

Megabytes have shown to be a bit clumsy in the configuration files, so
simply switch to the more useful Gigabytes unit.

Fixes #39

Allow setting the log level explicitly from "Warn", "Info", "Debug" or
"Trace" in the configuration.

Default is "Info", fallback for invalid settings is "Debug".

Fixes #34

Otherwise it will be missing when a grace cleanup email is being sent in
the startup phase.

Refers to #31

Refers to #31

Refers to #6, #25

Fixes #31

Note that they are not included in the example configuration files as
these settings can easily mess up everything and should only be adjusted
with great care.

The default settings are valid on Windows 7 and Server 2012 and were
successfully tested on those versions.

Fixes #11

This parameter has a different default setting with RoboCopy in the
Server 2012 version: "DA" (data and attributes), compared to "T"
(timestamps) on e.g. Windows 7.

Forcing this setting to be the same for 2012 and 7 seems to fix the
issue of files not being transferred. More testing is needed though!

Refers to #11

Disabling attributes and owner settings.

Refers to #11

Try to move the corresponding transfer package out of the processing
location to prevent it from being picked up again and producing the
same problem again, move it to the error location instead and reset the
transfer variables.

If a new directory is found in incoming but the move operation to
processing failed for some reason, the timestamp and username
directories (and potentially some partially moved data?) would remain
in processing. To prevent confusion about those "incomplete" transfer
candidates they are moved to the "ERROR" location.

Use a list to keep track of directories in the incoming directories that
couldn't be moved to the processing location and ignore them until the
service is restarted.

Refers to #9