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