This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: chere + mintty doesn't work with mapped drives


> -----Original Message-----
> From: Dave Kilroy [mailto:kilroyd@googlemail.com]
> On 01/12/2013 21:09, Corinna Vinschen wrote:
> > Are you starting mintty with "run as administrator" by any chance?
> Corrina's right - check that the same user is being used in both cases.
> I don't think this would explain why it's not working from the context menus
> though. Finding out why bash under mintty doesn't think /cygdrive/y/apps is
> a directory is the key.

SOLVED

Yes, I was starting mintty "as admin" and yes this was the culprit.
I was doing this by using a shortcut (similar, but not identical to the installed
"Cygwin Terminal" shortcut), that had the checkbox 
"Compatibility|Run this program as an administrator" enabled.

I ASSUMED this would only affect mintty when launched from this shortcut.

HOWEVER, it seems that this changes a property associated with mintty
regardless of how it is launched.  Apparently another "Wonder of Windows".

Unchecking the "run as admin" fixed the problem associated with accessing
the mapped drives everywhere (including the "Bash Prompt Here" xhere
Processing).

The reason I was running as admin was that many of the network centric
scripts that I use frequently during certain phases of various projects seem
to require admin privs and simply fail without any attempt to escalate (which
I seem to recall is due to a mismatch between the Windows and Unix
Security models).  I guess I'll have to rethink that approach.
 
Any suggestions on how to have a shortcut (or something similar) that
runs mintty as admin, but has no global effect on other mintty launches?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]