The thing that looks most suspicious is the set of SHARE VIOLATION
errors. I would guess this happened because msi.dll is busy, but
perhaps that is quite unexpected. One thing that you could try is
to close windows, then, from linux rename msi.dll to msi.dll.save,
and then bring windows back up and retry the installation. Of course
you might get some app complaining about the absense of msi.dll, but
that could be interesting too.
BTW, we might want to hire you now that you are an expert at reading
dos.logs. :-) Oh, and just an asside: Windows/DOS uses a "CHMOD" for
both getting and setting file attributes. So in Linux terms it maps
to both stat() and chmod(), depending on the flag.
Richard <rwb>
Ken Corbin wrote:
>
> Well, that was a time consuming, extremely intersting, but ultimately
> unsuccesful excercise. Problem was that there is about 58,000 lines in the
> trace file generated between the point where installation started and where it
> reported failing. Took some time to figure out how the basics of what was in
> this file and what was and wasn't important, then put in some filters to
> identify the important stuff.
>
> For some unknown and mysterious reason it was attempting to create a .TMP file
> on the J: drive which was getting kicked out with an ACCESS DENIED error.
> Which sounded hopeful. But enabling write access to that /var/win4lin/dosroot,
> while keeping the individual files write protected, didn't resolve the problem,
> though it did get rid of the ACCESS DENIED error returns.
>
> With the access change, there just isn't anything suspicious going on.
> I'm looking for any reported failure other than FIND FIRST or FIND NEXT,
> which I think I get with a filter of
> "SEQ .*([^I]ND|[^N]D|[^R]ST|[^S]T|[^TD])/([^S]|S[^U]|SU[^C]).*/ "
>
> RMDIR \IXP000.TMP fails with PATH NOT FOUND
> CHMOD \IXP000.TMP fails with FILE NOT FOUND
> MKDIR \IXP000.TMP succeeds
>
> CHMOD \IXP000.TMP\msiinst.exe fails with FILE_NOT_FOUND
> CHMOD \IXP000.TMP\msi.dll fails with FILE_NOT_FOUND
> CHMOD \WINDOWS\123r5.ini fails with FILE_NOT_FOUND
>
> CHMOD fails with FILE_NOT_FOUND on a number of files, immediately followed by a
> successful EXT_OPEN_CREATE on the same file, which looks reasonable.
>
> EXT_OPEN_CREATE \~MPI2350.TMP fails with FILE_NOT_FOUND
>
> EXT_OPEN_CREATE \WINDOWS\winit.ini fails with FILE_NOT_FOUND
>
> CHMOD failures on a number of files in \IXP000.TMP\ directory followed by
> succesful CHMOD of same file in \WINDOWS\ dirctory. Which also seems
> reasonable.
>
> CHMOD \WINDOWS\START MENU\PROGRAMS\Adminsitrative Tools fails with
> FILE_NOT_FOUND, followed by successful MAPNAME on \WINDOWS\START
> MENU\PROGRAMS, then a successful MKDIR adn RMDIR on \WINDOWS\START
> MENU\PROGRAMS\Adminsitrative Tools.
>
> EXT_OPEN_CREATE \WINDOWS\SYSTEM\msi.dll fails with SHARE_VIOLATION followed by
> successful CHMOD and EXT_OPEN_CREATE on same file. FIrst open call passed
> share mode of 01x. Second successful call passed share mode of 02x.
>
> CHMOD \Config.Msi fails with FILE_NOT_FOUND, followed by successful MKDIR and
> CHMOD on same file.
>
> Later there is a successful RMDIR of \Config.Msi, followed by two consequetive
> CHMOD Msi failurres, followed by successful MKDIR on same file. Odd behavior,
> but not explanation for a open log failure???
>
> EXT_OPEN_CREATE \WINDOWS\SYSTEM\msi.dll fails with SHARE_VIOLATION. Which is
> followed by a successful READ_SEQ. (?????)
>
> Sucessful RMDIR \Config.Msi followed by CHMOD failure on same file. Followed
> several secuessful READ_SEQ requests.
>
> EXT_OPEN_CREATE \WINDOWS\wininit.ini fails with FILE_NOT_FOUND
>
> CHMOD \WINDOWS\123r5.ini fails with FILE_NOT_FOUND
>
> EXT_OPEN_CREATE \~MPI3B1D.TMP fails with FILE_NOT_FOUND.
>
> CHMOD \WINDOWS\KESKTOP\desktop.ini fails with FILE_NOT_FOUND.
>
> CHMOD \WINDOWS\123r5.ini fails with FILE_NOT_FOUND
>
> CHMOD \~MPI3824.TMP fails with FILE_NOT_FOUND
>
> On Mon, 01 Jan 2001, you wrote:
> > > I've confirmed that I have write access to everythingWin4Lin knows about and
> > > don't know what to try next. I did try copying the programs from the
> > > installed Widnows partition, but that didn't work. Which isn't that surprising
> > > when you think about all of the undercover stuff Windows software installation
> > > requires nowdays.
> >
> > You can create what we call (for historical reasons) a "DOS Log" that will show
> > all of the filesystem transactions. You do this by doing the following:
> > sh -c 'DOS_LOG=ffff:/tmp/dos.log win &'
> >
> > Note that the log file can become quite big. Note also that if you don't seem
> > to get enough information you can use ffffffff instead of ffff (these are logging
> > masks) and you will get a huge log file but with pretty much everything you want.
> > The output is in /tmp/dos.log and can be pretty cryptic, but you can generally
> > get the idea of what is going on. Look towards the bottom to see if you can
> > tell what log file the installer was trying to open and write to.
> >
> > Richard <rwb>
> >
> > --
> > Richard Bass
> > NeTraverse, Inc.
> > mailto: [EMAIL PROTECTED]
> > _______________________________________________
> > Win4Lin-users mailing list
> > [EMAIL PROTECTED]
> > https://lists.netraverse.com/mailman/listinfo/win4lin-users
> _______________________________________________
> Win4Lin-users mailing list
> [EMAIL PROTECTED]
> https://lists.netraverse.com/mailman/listinfo/win4lin-users
--
Richard Bass
NeTraverse, Inc.
mailto: [EMAIL PROTECTED]
_______________________________________________
Win4Lin-users mailing list
[EMAIL PROTECTED]
https://lists.netraverse.com/mailman/listinfo/win4lin-users
