On our build infrastructure (using cygwin) we get this uname:
CYGWIN_NT-10.0-20348
So we need to check a bit more carefully

Now that windows supports hardlinks, we need to add them back to the
count, as they are not deleted in setup_data anymore.

Previously the iteration order depended on the c++ lib
implementation (and could also be change from run to run).  This lead
to issues where 'show job' would print jobs on linux but jobdefs on
windows.

To make sure that always the same element is chosen, we need to make
sure the order is always the same.  This is easily done by just using
a vector here.

Its important that error messages output what bareos thinks and not
what the user inputed (as the user knows that himself).

This caused a weird issue on windows when 'show job=<jobname>' was
interpreted as 'show jobdefs=<jobname>' which returned the error

job resource <jobname> not found.

Which is extremely misleading, as bareos never searched for a job in
that case.  If the error message would have been instead

jobdefs resource <jobname> not found.

then the user at least notices that bareos did something wrong and try
some other input instead of trying to understand why the job was not
found.

We replace /dev/null with a variable so that we can use NUL on windows
instead!

dangling-link does not get created on windows, so we need to chose a
different file.

You cannot set test properties on tests that do not exist.  Subtests
dont exist if you disable the main test, so this was leading to
configuration errors on windows.

This test requires a shell script + flock to function correctly.

This test runs multiple backups and, since vss takes a long time to
setup, runs into timeouts.  As such we disable VSS for this test.

Our fix for invalid paths messed up our handling for relative paths as
'.' was treated as an invalid character and was replaced.  This caused
the '.' that glob() generated to end up in an absolute path, which was
is not valid.

We can now also reenable the parser test as this was the only reason
that it did not work.

The old code did not handle ./.. correctly, so we should not try to
emulate that.
The long_file_name was not setup correctly, so I fixed that and added
a test that checked the previously checked behaviour.