This is the mail archive of the cygwin-apps 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: 1.7 installation failed (on network drive?)


On Dec  7 17:09, Thomas Wolff wrote:
> I've tested the network installation with last Saturday's update of
> setup-1.7.exe and unfortunately, the problem remains.
> However, I can add a screen log after calling setup from mintty for
> the case that setup cannot even store its log anywhere (attached).
> Don't know if that helps. Apparently setup-1-7.exe cannot create
> directories (including the top package directory) on that network
> NFTS drive, although all other tools can easily create them.
> Despite cgf's point this should not delay the 1.7.1 release, may I
> suggest once more (and I'm not adding this to the "1.7.1 release
> date" thread) that while the release is being delayed anyway due to
> other discussions, we might as well try to resolve this. Personally,
> I can do with a workaround; I'm just trying to help avoid trouble
> with other users complaining after "the release"...
> Thomas

I just had another look into this and unfortunately I still can't
reproduce it.  What I see in your log output is the fact that ...
hang on ...

> io_stream_cygfile: fopen(/etc/setup/timestamp) failed 13 Permission denied
> io_stream_cygfile: fopen(/var/run/utmp) failed 13 Permission denied
> io_stream_cygfile: fopen(/etc/setup/alternatives.lst.gz) failed 13 Permission denied
> [etc]

So the fopen calls fail.  fopen in setup is actually a call to nt_wfopen
in  If you could take a look, it's not a very complicated
function.  The general idea is to call NtCreateFile with
FILE_OPEN_FOR_BACKUP_INTENT rights to allow an admin to install without
permission trouble.

As you can see, the error handling (lines 466ff) is somewhat
oversimplified.  You get a "Permission denied" as a fallback error
if none of the path-related errors is triggered.  Unfortunately
we don't know the exact status code returned by NtCreateFile and
I have no real idea what the problem might be.

What we need is this:  Build a debug version of setup (you need gcc-3
for that since the -mno-cygwin option is still used), start it under
GDB, and set a breakpoint to  GDB will break there if
an error gets triggered.  Examine what status codes are returned.
See /usr/include/w32api/ddk/ntstatus.h what status code that is.

That might give us some clue.  The only vague idea what you could try
else is to remove the FILE_OPEN_REPARSE_POINT flag from the NtCreateFile
call and see if it works without that.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

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