1.7 installation failed (on network drive?)

[Thomas Wolff]

Corinna Vinschen wrote:
> Thomas,
>
> 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 filemanip.cc.  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.
>   
I have traced the status values returned by NtCreateFile (with printf 
actually), see the screen logs attached. I pasted in the popup error 
messages where they occurred.
There is a bunch of the following NtCreateFile problems in the log:
#define STATUS_ACCESS_DENIED ((NTSTATUS)0xC0000022L)
#define STATUS_OBJECT_NAME_INVALID ((NTSTATUS)0xC0000033L)
#define STATUS_OBJECT_NAME_NOT_FOUND ((NTSTATUS)0xC0000034L)
#define STATUS_OBJECT_PATH_NOT_FOUND ((NTSTATUS)0xC000003AL)
#define STATUS_OBJECT_PATH_SYNTAX_BAD ((NTSTATUS)0xC000003BL)

However, before the fatal error occurs, it's just "STATUS_ACCESS_DENIED" 
in both cases.

> 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 filemanip.cc:468.  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.
>   
I also ran it with gdb and could just see the same status code that' 
also in my trace log; don't know if there's any other gdb-retrieved 
information you'd like to see.

> 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.
>   
That makes no difference, I tried both versions. The flag is only used 
in filemanip.cc anyway while the problem occurs in mkdir.cc.
Hope this helps a little bit, maybe at least for coming up with further 
debug instructions.

Thomas
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setup.log-rootdir-on-net
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20091211/907a67fb/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: setup.log-packagedir-on-net
URL: <http://cygwin.com/pipermail/cygwin-apps/attachments/20091211/907a67fb/attachment-0001.ksh>