Re: Checking pgwin32_is_junction() errors

On 2022-08-01 Mo 01:09, Thomas Munro wrote:
> On Thu, Jul 28, 2022 at 9:31 PM Thomas Munro <thomas.munro@gmail.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.



I'll try it out on fairywren/drongo.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com