Re: Permission denied running programs in other directories

["Paul G." <pgarceau at qwest dot net>]

Hi folks,

disclaimer: can't say with certainty (99%) that what it appears to be is actually the case.  This is more like me thinking 
out loud than anything else.

On 15 Dec 2001 at 18:42, Chris Bagwell wrote:

> Hello,
> 
> I am having problems running some development programs and could use
> some help.
> 
> I have been using Cygwin successfully running Windows 98.  Actually,
> I'm running it under Linux using the program Win4Lin.  This causes the
> filesystem to appear a little differently then under real windows
> since its not using direct-to-disk FAT drivers.  I'm sure this is
> related to part of the problem.  I'm not sure but they may be treated
> as network drives.

	It really looks to be very similar to a /root vs. Win4Lin /root access conflict.
> 
> Somewhere after a cygwin upgrade I noticed that when I tried to
> compile programs it would give me the following error:
> 
> gcc: installation problem, cannot exec 
> '/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-5/../../../../i686-pc-cygwin/b
> in/as.exe': Permission denied

	Again, it may be that you are getting conflicts between what Win4Lin considers /root and what your Linux 
system thinks of as $ROOT.  (You may need to give Win4Lin su status.  Just a guess based on behavior I noted 
when I used Linux extensively many years ago, but seems to make sense.)

	I am not familiar with how Win4Lin sets things up.  Believe (again, not certain) that setup.exe determines 
Cygwin /root when it does an "install from web".  Under MS Windows, the assumption is that once Cygwin /root is set 
it does not need to be re-initialized, not ever.  (Linux needs to always have /root defined.)  Now, if Linux is over-riding 
or re-defining $ROOT settings when Win4Lin is shut down, it would make sense that the Cygwin /root would always 
need to be re-initialized/defined whenever Win4Lin is restarted.  In extreme cases, this could be accomplished with 
some sort of SU priority shell script which is run whenever Win4Lin is launched.

> 
> I am able to reproduce the same error if I type the follow from the
> bash prompt:
> 
> /usr/i686-pc-cygwin/bin/as.exe
> BASH: /usr/i686-pc-cygwin/bin/as.exe: Permission denied
> 
> It will run fine if I run it from within that directory:

	ok...so when PWD is set to /usr/i686-pc-cygwin/bin:
> 
> cd /usr/i686-pc-cygwin/bin
> as.exe
> [starts accepting input until I type ctrl-d]

	It works until you try and access a term i/o (console?) directive.

	Other possibility, you're missing a $PATH$ or symlink(hard) reference.  Again, uncertain on this, so it is 
largely speculation, ctrl-d is typically a call to Cygwin console/term driver, isn't it?  Does ctrl-d run when $PWD is set 
(Win4Lin) to Cygwin /root (Under MS-Windows <somedrv:\somedirname> is defined as "Cygwin /root" -- same likely 
applies for Win4Lin)?

	Again, looks like a conflict between what Cygwin considers "/root" for MS-Windows and what Linux considers 
/root for System ($ROOT) once Win4Lin (process?) has been shut down and restarted.

> 
> For some extra strange stuff, if I run "strace 
> /usr/i686-pc-cygwin/bin/as.exe" I get the following message:
> 
> strace.xe: error creating process /usr/i686-pc-cygwin/bin/as.exe,
> (error 2)

	Looks like user priority ("Linux su" vs. "Linux user") conflict.
> 
> And finally, if I reinstall the binutil package using the setup
> program then it starts working... By that I mean it works until I shut
> down windows... When I restart it I will get the same behavior as
> described above.  Its as if the setup program is enabling some file or
> directory permissions that are not setup upon bootup.

	Hope this helps.

	Paul G.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/