http://bugs.winehq.org/show_bug.cgi?id=8439
--- Comment #16 from Anastasius Focht focht@gmx.net 2008-03-29 19:25:13 --- Created an attachment (id=11733) --> (http://bugs.winehq.org/attachment.cgi?id=11733) patch which prevents incorrect write-protect attributes on file targets
Hello,
another patch to get full installation working. This was a bit nasty to investigate/debug because the VS.NET installer takes a huge nap until the real installation of components starts (30-60 minutes depending on machine speed). I hope James will optimize the table joins one day further (low priority).
Prerequisite: clean ~/.wine, winetricks vcrun6 gecko, shell32 patch applied
As I already outlined in another VS.NET bug report, the AeDebug "Auto" key gets modified in early stage (by ms debugging service component -> "0"). This has the consequence that in case of unhandled exceptions, winedbg is no longer automagically runaway-spawned, hiding possible problems. Instead "nice" message boxes are popping up, asking the user what to do. So all that is needed is to prevent any unhandled exceptions caused by component installers ;-)
When the "mobile device support" component within VB.NET component is selected, the .NET compact framework is installed too (= default). Unfortunately this leads to a problem at late installation stage which unearths msi bug.
There is a small .NET executable temporarily extracted and spawned with the following command line:
--- snip --- genxml.exe "C:\Program Files\Microsoft Visual Studio .NET 2003\Setup\conman_ds_package.xsl" "C:\windows\profiles\All Users\Application Data\Microsoft\VisualStudio\Devices\7.1\conman_ds_package.xsl" "C:\Program Files\Microsoft Visual Studio .NET 2003\CompactFrameworkSDK\ConnectionManager\Bin" "C:\Program Files\Microsoft Visual Studio .NET 2003\CompactFrameworkSDK\ConnectionManager\Target" "C:\windows\profiles\All Users\Application Data\Microsoft\VisualStudio\Devices\7.1" "C:\Program Files\Microsoft Visual Studio .NET 2003\CompactFrameworkSDK\v1.0.5000" C:\windows\Microsoft.NET\Framework\v1.1.4322 "C:\Program Files\Microsoft Visual Studio .NET 2003\CompactFrameworkSDK\ConnectionManager\Bin" --- snip ---
(I renamed it for my own purpose to debug it)
This tool throws unhandled (managed) exception.
--- snip managed exception frame --- First chance exception generated: (0x04790188) <System.UnauthorizedAccessException> Unhandled exception generated: (0x04790188) <System.UnauthorizedAccessException> _className=<null> _exceptionMethod=<null> _exceptionMethodString=<null> _message=(0x0478ff84) "Access to the path "C:\windows\profiles\All Users\Application Data\Microsoft\VisualStudio\Devices\7.1\conman_ds_package.xsl" is denied." _innerException=<null> _helpURL=<null> _stackTrace=(0x047901c8) array with dims=[96] _stackTraceString=<null> _remoteStackTraceString=<null> _remoteStackIndex=0x00000000 _HResult=0x80070005 _source=<null> _xptrs=0x00000000 _xcode=0xe0434f4d --- snip managed exception frame ---
The managed code for that small app resembles like this:
--- snip managed app code --- .. if (File.Exists(path)) { StreamReader reader = File.OpenText(path); str = reader.ReadToEnd(); reader.Close(); str = str.Replace( ... values_supplied_with_commandline_args ... ); StreamWriter writer = File.CreateText(str3); writer.Write(str); writer.Close(); } .. --- snip managed app code ---
Badly written ... there is no exception handler which guards StreamReader/Writer and other file operation failures.
The corresponding wine trace:
--- wine trace --- 0009:Call KERNEL32.GetFullPathNameW(0033f22c L"C:\windows\profiles\All Users\Application Data\Microsoft\VisualStudio\Devices\7.1\conman_ds_package.xsl",00000105,0033f020,0033efe8) ret=791bd775 0009:Ret KERNEL32.GetFullPathNameW() retval=00000067 ret=791bd775 .. 0009:Call KERNEL32.CreateFileW(0477a7a8 L"C:\windows\profiles\All Users\Application Data\Microsoft\VisualStudio\Devices\7.1\conman_ds_package.xsl",40000000,00000001,00000000,00000002,00000080,00000000) ret=003fa308 0009:Ret KERNEL32.CreateFileW() retval=ffffffff ret=003fa308 0009:Call KERNEL32.GetLastError() ret=003fa30e 0009:Ret KERNEL32.GetLastError() retval=00000005 ret=003fa30e .. <managed exception later> --- wine trace ---
What happens? Let's look into that target directory:
--- snip --- [focht@nexus 7.1]$ ls -lsa .. 8 -r--r--r-- 1 focht focht 2487 2003-03-19 08:44 conman_ds_package.xsl 32 -r--r--r-- 1 focht focht 26432 2003-03-19 08:44 conman_ds_platform.xsl 8 -r--r--r-- 1 focht focht 1621 2003-03-19 08:44 conman_ds_startup.xsl 8 -r--r--r-- 1 focht focht 3365 2003-03-19 08:44 conman_ds_transport.xsl --- snip ---
The files were installed by VS.NET installer at earlier stage - and have write-protection set (mounted DVD ISO). This is the cause of the exception when the output file is to be opened.
Msi's copy_file() calls CopyFileW() (dlls/kernel32/path.c) at some point to copy files from source media to target. CopyFileW's target inherits the source file attributes -> GetFileInformationByHandle( source ...) -> DVD ISO, hence the target "write protect".
When I looked at other installed files, I noticed a strange thing... Various files were write-protected and some not.
--- snip target (wine drive_c) --- [focht@nexus VS7Debug]$ pwd /home/focht/.wine/drive_c/Program Files/Common Files/Microsoft Shared/VS7Debug [focht@nexus VS7Debug]$ ls -lsa .. 64 -r--r--r-- 1 focht focht 57344 2003-03-19 10:56 coloader.dll 12 -r--r--r-- 1 focht focht 5120 2003-03-19 03:24 coloader.tlb 64 -rw-rw-r-- 1 focht focht 57344 2003-03-19 10:56 csm.dll 336 -rwxrwxr-x 1 focht focht 335872 2003-03-19 10:55 mdm.exe 196 -rw-rw-r-- 1 focht focht 192512 2003-03-19 10:58 msdbg2.dll 196 -rw-rw-r-- 1 focht focht 192512 2003-03-19 11:00 pdm.dll 196 -rwxrwxr-x 1 focht focht 192512 2003-03-19 07:23 vs7jit.exe --- snip target (wine drive_c) ---
--- snip source (mounted DVD iso) --- [focht@nexus vs7debug]$ pwd /mnt/iso/program files/common files/microsoft shared/vs7debug [focht@nexus vs7debug]$ ls -lsa .. 56 -r-xr-xr-x 1 root root 57344 2003-03-19 10:56 coloader.dll 5 -r-xr-xr-x 1 root root 5120 2003-03-19 03:24 coloader.tlb 56 -r-xr-xr-x 1 root root 57344 2003-03-19 10:56 csm.dll 328 -r-xr-xr-x 1 root root 335872 2003-03-19 10:55 mdm.exe 188 -r-xr-xr-x 1 root root 192512 2003-03-19 10:58 msdbg2.dll 188 -r-xr-xr-x 1 root root 192512 2003-03-19 11:00 pdm.dll 188 -r-xr-xr-x 1 root root 192512 2003-03-19 07:23 vs7jit.exe --- snip source (mounted DVD iso) ---
At certain installer stages, components are (re)installed again (no skip condition met). For example some tools ship with .NET Framework SDK and the same tools ship with VS.NET 7.1 main installer.
Msi encounters a permission problem while copying the files again (STATUS_ACCESS_DENIED -> NTSTATUS = 0xC0000022). The "copy_install_file Overwriting existing file: 0" indicates that msi fixed it by adjusting file attributes to "normal". This is the explanation why there is a mixture of write-protected and non-write-protected files.
Now the real problem: msi's copy_install_file()/copy_file() doesn't honour the "File" Table, "Attribute" column in case of attribute "none/normal". If you use ORCA tool on .msi "File" table you will see various files with zero attribute value (while others have 0x400 = readonly):
--- snip VS.NET msi "file" table data --- conman_ds_package_xml_1________.3643236F_FC70_11D3_A536_0090278A1BB8 SDE_ConMan_AppData_Devices________.3643236F_FC70_11D3_A536_0090278A1BB8 132950|conman_ds_package.xsl 2487 0 17472 --- snip VS.NET msi "file" table data ---
"0" means "normal" attributes
I attached a small patch which resets the target attributes to "normal" if necessary. This lets the VS.NET 2003 enterprise edition installer finish a full installation (= all components selected). Though the separate MSDN library sub-installer has a problem which I will look later into.
Anyway ... even with a full installation now succeeding this doesn't necessarily mean VS.NET works. There are various installer gaps which lead to later problems. I already mentioned the most prominent: msi not publishing assemblies into GAC/SxS.
Regards
-
wine-bugs＠winehq.org