On Fri, Oct 1, 2010 at 1:06 PM, Craig Ringer
<craig@xxxxxxxxxxxxxxxxxxxxx> wrote:
> On 10/01/2010 06:30 PM, Dave Page wrote:
>
>>> As for 2, I suspect that somewhere in the installer, it walks down the
>>> path
>>> to the TEMP directory, and fails at the junction because it cannot read
>>> the
>>> contents of its target directory.
>>
>> I've asked BitRock to confirm or deny that.
>
> It should be pretty trivial to test with Process Monitor. As I don't think
> my (English) system will have that junction point, I'm not sure I can
> observe the results with junction points, but I can certainly see if the
> installer is trying to walk the path.
>
> [clickety click]
>
> Yes, the installer walks the path. For each directory it does:
>
> FASTIO_NETWORK_QUERY_OPEN ("QueryOpen")
> FASTIO_QUERY_INFORMATION ("QueryOpenNetworkInformation")
> IRP_MJ_DIRECTORY_CONTROL ("QueryDirectory")
>
> (see the attached screenshot)
>
> IRP_MJ_DIRECTORY_CONTROL is documented in MSDN as:
> http://msdn.microsoft.com/en-us/library/ff548658(VS.85).aspx
>
> The rest, I have no idea about. I don't do Windows innards by choice.
You would think it would walk backwards in the event of an error
rather than the other way round. Anyway, BitRock should be able to
tell us, unless it's their underlying toolkit/language/SDK that's
doing it.
> I wonder why it's walking the path? Such things are rarely a good idea,
> unless you're trying to backtrack on an access denied error to find out at
> what level of a path you lost access.
Right :-) I really should read to the end before commenting.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise Postgres Company
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
