Re: cygwin.bat fails with "WFMO failed waiting for cygthread 'WnetGetResourceInformation'
On Fri, Jun 10, 2005 at 10:30:53AM +0200, Corinna Vinschen wrote: >On Jun 6 11:39, Tim Hart wrote: >> All, >> >> My XP machine is currently unable to connect to my Windows domain before >> logging in. Windows uses cached information to accept my domain login. I >> then VPN to my domain, and life is good. >> >> If my VPN connection is established, then Cygwin works just fine. If, >> however, I am not connected to my VPN, then I see the message: >> >> C:\cygwin\bin\bash.exe (1672): *** WFMO failed waiting for cygthread >> 'WnetGetResourceInformation' > >Could you please try the same layout you had when this error occured >with the latest snapshot DLL from http://cygwin.com/snapshots/, please? >Even if it doesn't solve the problem, it has an improved debugging >output which should help us to see why this occurs. I think I fixed this problem a couple of days ago so it should no longer be an issue. FYI, cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.bat fails with "WFMO failed waiting for cygthread 'WnetGetResourceInformation'
On Jun 6 11:39, Tim Hart wrote: > All, > > My XP machine is currently unable to connect to my Windows domain before > logging in. Windows uses cached information to accept my domain login. I then > VPN to my domain, and life is good. > > If my VPN connection is established, then Cygwin works just fine. If, > however, I am not connected to my VPN, then I see the message: > > C:\cygwin\bin\bash.exe (1672): *** WFMO failed waiting for cygthread > 'WnetGetResourceInformation' Could you please try the same layout you had when this error occured with the latest snapshot DLL from http://cygwin.com/snapshots/, please? Even if it doesn't solve the problem, it has an improved debugging output which should help us to see why this occurs. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.bat fails with "WFMO failed waiting for cygthread 'WnetGetResourceInformation'
On Jun 8 11:01, Tim Hart wrote: > On Jun 7 19:06, Tim Hart wrote: > >> having the same home directory path. I can use a few pattern matching tools > >> to filter out the appropriate domain users and modify /etc/passwd > >> accordingly. Obviously mkpasswd needs to be updated in order to produce > >> correct home directory entries (possibly a unique format for Windows XP?). > > >The information returned by Windows is used unchanged. There should be > >no need for some special handling. > > In this case mkpasswd isn't using any information returned by Windows other > than the homeroot > prefix. > > The full command ( for reference ), is > > mkpasswd -d -l -p "$(cygpath -H)" > /etc/passwd > > mkpasswd -d -l is returning information on two different users: the local > TJHart and > CORPORATE\TJHart. The -p option overwrites any directories returned by Windows. mkpasswd has no intelligence built in. It just appends the user name to the path given by -p, nothing else. If you leave out the -p option you'll get the home directory return by the Windows function NetUserEnum. If there hasn't been stored any homedir in the SAM, you get /home/username. If the NetUserEnum function doesn't return the correct path, there's no way to get what you want which I'm aware of. I don't know how NT generates different paths for the same user name in different Domains. If you need a more complex layout, either manipulate the resulting passwd file by hand or consider to write a patch to mkpasswd. You know, http://cygwin.com/acronyms/#SHTDI and http://cygwin.com/acronyms/#PTC ;-) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.bat fails with "WFMO failed waiting for cygthread 'WnetGetResourceInformation'
On Jun 7 19:06, Tim Hart wrote: >> having the same home directory path. I can use a few pattern matching tools >> to filter out the appropriate domain users and modify /etc/passwd >> accordingly. Obviously mkpasswd needs to be updated in order to produce >> correct home directory entries (possibly a unique format for Windows XP?). >The information returned by Windows is used unchanged. There should be >no need for some special handling. In this case mkpasswd isn't using any information returned by Windows other than the homeroot prefix. The full command ( for reference ), is mkpasswd -d -l -p "$(cygpath -H)" > /etc/passwd mkpasswd -d -l is returning information on two different users: the local TJHart and CORPORATE\TJHart. mkpasswd is, on it's own (without Windows help at all)appending the user name to that path in order to define a unique home directory for each user at the path indicated by the -p switch. In this case, cygpath -H returns /cygdrive/c/Documents and Settings. Unfortunately, mkpasswd's scheme doesn't guarantee unique paths for each user. If there was a TJHart in the SFO domain, then they, too would be mapped to the SAME home directory according to mkpasswd's scheme. TJHART gets mapped to /cygdrive/c/Documents and Settings/TJHART (local user) CORPORATE\TJHART also gets mapped to /cygdrive/c/Documents and Settings/TJHART SFO\TJHART also gets mapped to /cygdrive/c/Documents and Settings/TJHART Unfortunately these users are NOT the same user and shouldn't, by default, be mapped to the same home directory. Windows creates a unique home directory for the user the first time they log into the machine. I do not know if the user's domain is appended to the home directory name in every case, or only in cases of conflict. I do know that my machine is used by 2 distinct users: a local TJHART, and a CORPORATE\TJHART. Windows accomodates local storage for these 2 users by creating 2 distinct home directories: /cygdrive/c/Documents and Settings/TJHART (local TJHART) /cygdrive/c/Documents and Settings/TJHART.CORPORATE (CORPORATE\TJHART) Since the goal of mkpasswd is to simplify creation of the passwd file for the cygwin environment, then I would expect that default behavior should be to map each user retreived to a unique directory. Ideally, I would hope that this directory would be the same one that the Windows operating system would use. When you omit the -p command, then mkpasswd's behavior is exactly correct. However, with the '-p' option,the user name without the domain isn't sufficiently unique to guarantee unique home directories for every user with permission to access a particular machine. Modification of the file for the exception is certainly possible, but shouldn't be necessary for the general case. Perhaps the -p switch isn't the right utility for this problem. There is no option in mkpasswd to append a suffix to the home directory path, which is what Windows does. Possibly another command-line switch to indicate that the user's HOMEPATH should be used for the home directory instead of the indicated HOME? I've been unable to find any cygwin utilities that provide such a complete path for a user other than the current one. Even if I had, mkpasswd only offers me the possibility of providing a prefix, not the entire home directory path. >> Perhaps the cygwin routine producing the error could provide some more >> useful information in the >future? Such as the fact that a network resource wasn't found - and the name >of the resource? >No, no, you got that wrong. The error message you saw (WFMO, blah) is >actually indicating a bug in Cygwin. You should get something like >"file not found" or so, but certainly not this WFMO message you saw, >which is only meaningful to Cygwin developers. Do you need additional information for this particular part of the problem? Tim -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.bat fails with "WFMO failed waiting for cygthread 'WnetGetResourceInformation'
On Jun 7 19:06, Tim Hart wrote: > having the same home directory path. I can use a few pattern matching tools > to filter out the appropriate domain users and modify /etc/passwd > accordingly. Obviously mkpasswd needs to be updated in order to produce > correct home directory entries (possibly a unique format for Windows XP?). The information returned by Windows is used unchanged. There should be no need for some special handling. > Perhaps the cygwin routine producing the error could provide some more useful > information in the future? Such as the fact that a network resource wasn't > found - and the name of the resource? No, no, you got that wrong. The error message you saw (WFMO, blah) is actually indicating a bug in Cygwin. You should get something like "file not found" or so, but certainly not this WFMO message you saw, which is only meaningful to Cygwin developers. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.bat fails with "WFMO failed waiting for cygthread 'WnetGetResourceInformation'
>This has nothing to do with security but with accessing shares on the >network. Apparently you're accessing shares which are only available >when the VPN is up and this *somehow* results in some internal problem. >Unfortunately you're only giving very basic information. Please have a >look into http://cygwin.com/problems.html and follow the guidelines for >reporting problems. Especially add some clue how shares come into play. >Any share you're accessing always in, say, your .bashrc? Yes? No? How? Great - now that I have a better understanding of the issue I can gladly provide useful information. cygcheck.out attached. If I'm attached to my domain, my windows command line defaults the current directory to the path pointed to by the 'HOME' environment variable. If not, it uses the HOMEPATH environment variable. I have not defined any .bashrc. The installation is plain vanilla cygwin. I have run mkpasswd & mkgroup while connected to my domain. In each case I included the command line switch for domain information If I'm attached to the VPN (domain) and start cygwin.bat, then I end up with a typical prompt at [EMAIL PROTECTED] ~ where '~' is also the value provided by 'HOME', and (obviously) the value of the home directory field in /etc/passwd. My HOME is defined as a network location - \\Haggis\tjhart. While I am an administrator of my machine, I do not have the administrative rights in the domain to change this. The previous version of cygwin (1.5.16) dumped me in /etc/skel. While I would have preferred HOMEPATH (/cygdrive/c/Documents\ and\ Settings/TJHart.CORPORATE), I still had access to bash and was content. Based on your comments above I have been able to perform some tests. I DO have the rights to define a HOME environment variable in my own user space, which supersedes the HOME environment variable defined elsewhere (Default Windows? on the user profile in the domain?). I have tested this and it is an acceptable, but not preferred work-around. I have also re-generated /etc/passwd using the following configuration: mkpasswd -l -d -p "$(cygpath -H)" > /etc/passwd. This allows bash to start when I'm not connected to domain network resources. Unfortunately, it produces an incorrect home directory entry of /cygdrive/c/Documents and Settings/TJHart instead of the correct /cygdrive/c/Documents and Settings/TJHart.CORPORATE. This results in the user CORPORATE\TJHART and the local user TJHART having the same home directory path. I can use a few pattern matching tools to filter out the appropriate domain users and modify /etc/passwd accordingly. Obviously mkpasswd needs to be updated in order to produce correct home directory entries (possibly a unique format for Windows XP?). While the error message provided by bash/cygwin provided only VERY basic information (certainly insufficient to those without a familiarity with the Win32 network API), your more complete, accurate, and precise explanation of the problem was more than sufficient for me to solve the problem. Given that cygwin.bat uses the -login option for startup, I am comfortable with it's behavior. Perhaps the cygwin routine producing the error could provide some more useful information in the future? Such as the fact that a network resource wasn't found - and the name of the resource? > > >Corinna > >-- >Corinna Vinschen Please, send mails regarding Cygwin to >Cygwin Project Co-Leader mailto:cygwin@cygwin.com cygcheck.out Description: Binary data -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.bat fails with "WFMO failed waiting for cygthread 'WnetGetResourceInformation'
On Jun 6 11:39, Tim Hart wrote: > All, > > My XP machine is currently unable to connect to my Windows domain before > logging in. Windows uses cached information to accept my domain login. I then > VPN to my domain, and life is good. > > If my VPN connection is established, then Cygwin works just fine. If, > however, I am not connected to my VPN, then I see the message: > > C:\cygwin\bin\bash.exe (1672): *** WFMO failed waiting for cygthread > 'WnetGetResourceInformation' > > This behavior is different than on previous versions of Cygwin - I could > launch bash(cygwin.bat) just fine whether or not I was connected to the > domain. > > If this change is intentional, then I would like to discuss the matter. Are > you really beefing up security by not allowing me to run bash & the cygwin > subsystem? Even though Windows accepts the login and will let me run anything > else that doesn't require Domain resources? This has nothing to do with security but with accessing shares on the network. Apparently you're accessing shares which are only available when the VPN is up and this *somehow* results in some internal problem. Unfortunately you're only giving very basic information. Please have a look into http://cygwin.com/problems.html and follow the guidelines for reporting problems. Especially add some clue how shares come into play. Any share you're accessing always in, say, your .bashrc? Yes? No? How? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cygwin.bat fails with "WFMO failed waiting for cygthread 'WnetGetResourceInformation'
All, My XP machine is currently unable to connect to my Windows domain before logging in. Windows uses cached information to accept my domain login. I then VPN to my domain, and life is good. If my VPN connection is established, then Cygwin works just fine. If, however, I am not connected to my VPN, then I see the message: C:\cygwin\bin\bash.exe (1672): *** WFMO failed waiting for cygthread 'WnetGetResourceInformation' This behavior is different than on previous versions of Cygwin - I could launch bash(cygwin.bat) just fine whether or not I was connected to the domain. If this change is intentional, then I would like to discuss the matter. Are you really beefing up security by not allowing me to run bash & the cygwin subsystem? Even though Windows accepts the login and will let me run anything else that doesn't require Domain resources? Result of 'uname -a' is CYGWIN_NT-5.1 hartt 1.5.17(0.129/4/2) 2005-05-25 19:38 i686 unknown unknown Cygwin cygwin.bat has not been altered. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
