Cudos to Lei and everyone else who found the real problem.
It appears that Wine's implementation of the NtQueryDirectoryFile and all other functions that ending up calling it have a major problem. They will fail if called on symlinks into directories outside $WINEPREFIX which contain $WINEPREFIX itself (aka loop scenarios). Ex:
c:\windows\profiles\vitaliy\Desktop -> $HOME/Desktop - works c:\windows\profiles\vitaliy\My Documents -> $HOME - does not
The reason of this is clear - we have to stop any "loops" that are not common on windows (but possible with reparse points). There are lots of "smart" programs that will scan all of available drives and of course they will lock up in the never ending cycle if loops are allowed.
However, as I recall this configuration was a result of the long discussion about desktop integration. And use of symlinks was the best solution. It appears it is not a solution. Quite an opposite - it just plain doesn't work.
So should we go back to the drawing board and and rethink our approach to the desktop integration? Also what can we do, if user configures such a loops him/her self?
Vitaliy Margolen
Am Sonntag 29 April 2007 01:05 schrieb Vitaliy Margolen:
Cudos to Lei and everyone else who found the real problem.
It appears that Wine's implementation of the NtQueryDirectoryFile and all other functions that ending up calling it have a major problem. They will fail if called on symlinks into directories outside $WINEPREFIX which contain $WINEPREFIX itself (aka loop scenarios). Ex:
So should we go back to the drawing board and and rethink our approach to the desktop integration? Also what can we do, if user configures such a loops him/her self?
Hide the wine prefix dir from the application? This won't fix some natural loops in normal unix directory structures, like my distro has /usr/X11R6 set up as a symlink to /usr. The problem is not limited to Desktop integration, although in this case it is made by wine itself.
-
Stefan Dösinger -
Vitaliy Margolen