On Sat, Mar 26, 2022 at 6:33 PM Michael Paquier <michael@paquier.xyz> wrote:
> Ah, good point. I have not tested on Windows so I am not 100% sure,
> but indeed it would make sense to reverse both conditions if a
> junction point happens to be marked as both FILE_ATTRIBUTE_DIRECTORY
> and FILE_ATTRIBUTE_REPARSE_POINT when scanning a directory. Based on
> a read of the the upstream docs, I guess that this is the case:
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-fscc/ca28ec38-f155-4768-81d6-4bfeb8586fc9
>
> Note the "A file or directory that has an associated reparse point."
> for the description of FILE_ATTRIBUTE_REPARSE_POINT.
That leads to the attached patches, the first of which I'd want to back-patch.
Unfortunately while testing this I realised there is something else
wrong here: if you take a basebackup using tar format, in-place
tablespaces are skipped (they should get their own OID.tar file, but
they don't, also no error). While it wasn't one of my original goals
for in-place tablespaces to work in every way (and I'm certain some
external tools would be confused by them), it seems we're pretty close
so we should probably figure out that piece of the puzzle. It may be
obvious why but I didn't have time to dig into that today... perhaps
instead of just skipping the readlink() we should be writing something
different into the mapfile and then restoring as appropriate...