On Sat, Feb 15, 2014 at 1:26 PM, Amit Kapila <
amit.kapila16@gmail.com> wrote:
> On Fri, Feb 14, 2014 at 8:27 AM, Bruce Momjian <
bruce@momjian.us> wrote:
> > On Tue, Jan 7, 2014 at 12:33:33PM +0530, Amit Kapila wrote:
> >> Still they have not told anything about other API's
> >> (rmdir, RemoveDirectory) which has same problem.
> >
> > Where are we on this?
>
> Till now we didn't received any workaround which can fix this problem
> from Microsoft. From the discussion over support ticket with them,
> it seems this problem is in their kernel and changing the code for
> it might not be straight forward for them, neither they have any clear
> alternative.
Reply from Microsoft is as below.
"This is regarding a long pending case where stat() was failing on
hard links and causing an infinite loop. We have discussed this
multiple times internally and unfortunately do not have a commercially
viable solution to this issue. Currently there are no workarounds
available for this issue, but this has been marked for triage in future
OSes. Since we have out run the maximum time that can be spent
on this Professional Level Service request, I have been asked to
move ahead and mark this as a won’t fix. We would need to close
this case out as a won’t fix, and you would not be charged for this
incident."
> > Is there a check we should add in our code?
>
> We can possibly solve this problem in one of the below ways:
>
> 1. Resolve symbolic link to actual path in code whenever we tries to
> access it.
>
> 2. Another way is to check in code (initdb and create tablespace)
> to not allow path of length more than ~120 for Windows.
>
> Approach-1 has benefit that it can support the actual MAX_PATH and
> even if MS doesn't resolve the problem, PostgreSQL will not face it.
>
> Approach-2 is straightforward to fix. If we want to go with Approach-2,
> then we might change the limit of MaxPath for windows in future
> whenever there is a fix for it.
From the reply above, it is clear that there is neither a workaround
nor a fix for this issue in Windows. I think now we need to decide on
which solution we want to pursue for PostgreSQL. Does any one of
the above approaches seems sensible or let me know if you have any
other idea to solve this problem.
