An error here will typically mean that the directory was removed between
the time we iterated the parent and the time we wanted to visit it in
which case we should ignore it.

Other kinds of errors such as permissions (or transient errors) also
better dealt with by pretending we didn't see it.

We don't want the iterator to make us stop whenever we hit an unreadable
dir. We should instead move over to the next item.

Fixes issue #3338

Without this change, compiling with gcc and pedantic generates warning:
ISO C does not allow extra ‘;’ outside of a function.

For such a path '/~/...' the leading '/' is stripped so the server will
get a path starting with '~' and correctly handle it.

When we fail to rename, we currently leave the lockfile laying
around. This shows that behaviour.

When we have an error renaming the lockfile, we need to make sure
that we remove it upon cleanup. For this, we need to keep track of
whether we opened the file and whether the rename succeeded.

If we did create the lockfile but the rename did not succeed, we
remove the lockfile. This won't protect against all errors, but
the most common ones (target file is open) does get handled.