Re: Checking pgwin32_is_junction() errors

On Thu, Jul 28, 2022 at 9:31 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> There's one curious change in the draft patch attached: you can't
> unlink() a junction point, you have to rmdir() it. Previously, things
> that traverse directories without ever calling pgwin32_is_junction()
> would see junction points as S_ISDIR() and call rmdir(), which was OK,
> but now they see S_ISLNK() and call unlink(). So I taught unlink() to
> try both things. Which is kinda weird, and not beautiful, especially
> when combined with the existing looping weirdness.

Here's a new attempt at unlink(), this time in its own patch. This
version is a little more careful about calling rmdir() only after
checking that it is a junction point, so that unlink("a directory")
fails just like on Unix (well, POSIX says that that should fail with
EPERM, not EACCES, and implementations are allowed to make it work
anyway, but it doesn't seem helpful to allow it to work there when
every OS I know of fails with EPERM or EISDIR). That check is racy,
but should be good enough for our purposes, no (see comment for a note
on that)?

Longer term, I wonder if we should get rid of our use of symlinks, and
instead just put paths in a file and do our own path translation. But
for now, this patch set completes the set of junction point-based
emulations, and, IMHO, cleans up a confusing aspect of our code.

As before, 0001 is just for cfbot to add an MSYS checkmark.