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

This commit is successfully tested to work on Windows 7 with the latest
version of RoboSharp (at the time of writing, including the
[EnableRaisingEvents fix][1] which has not yet been merged upstream).

This closes #15

[1]: https://github.com/tjscience/RoboSharp/pull/46

Refers to #3, #11, #15

The shared approach results in conflicts if the generated class is used
in ATxCommon which is imported in the other projects. This way we can
use the symbols defined via ATxCommon in all depending projects.

The downside is that it slows down the build-process a bit as every
build from a project depending on ATxCommon (read: all others) will
change the generated code and thus force a re-build of ATxCommon and
the project itself. Since building the entire solution is still just
a matter of seconds, that's a fair trade-off.