[issue12201] Returning FILETIME is unsupported in msilib.SummaryInformation.GetProperty()
New submission from Mark Mc Mahon : In _msi.c, summary_getproperty() and summary_setproperty() raise an exception if the type being set/got is VT_FILETIME. This issue is to track adding support for (or declining to support) FILETIMEs in msilib.SummaryInformation.GetProperty()/SetProperty(). I have included a patch which adds this support (with some basic tests). Should this function accept/return datetime.datetime - or a timestamp (both require conversion anyway). I have used datetimes in my patch. -- components: Windows files: add_FILETIME_support_to_summary_info.patch keywords: patch messages: 137130 nosy: loewis, markm priority: normal severity: normal status: open title: Returning FILETIME is unsupported in msilib.SummaryInformation.GetProperty() versions: Python 3.2 Added file: http://bugs.python.org/file22163/add_FILETIME_support_to_summary_info.patch ___ Python tracker <http://bugs.python.org/issue12201> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12202] Check status returns in msilib.SummaryInformation.GetProperty()
New submission from Mark Mc Mahon : Per Eric V. Smith's comment issue1104 (msg134976) the return value of the call MsiSummaryInfoGetProperty() in summary_getproperty() (pc\_msi.c) is only checked for the error return ERROR_MORE_DATA. Other error values should be checked. -- messages: 137132 nosy: loewis, markm priority: normal severity: normal status: open title: Check status returns in msilib.SummaryInformation.GetProperty() ___ Python tracker <http://bugs.python.org/issue12202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character
Mark Mc Mahon added the comment: Responding to Eric's comments 1. There are only three valid property types returned by MsiInteger, String & FILETIME. (http://msdn.microsoft.com/en-us/library/aa372045%28v=VS.85%29.aspx) 2. That comment makes sense - I have entered a new issue (issue12202) for that. 3. Per 1. - there shouldn't be any other unhandled types. I have entered issue issue12201 to track adding support for FILETIMEs. -- ___ Python tracker <http://bugs.python.org/issue1104> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12202] Check status returns in msilib.SummaryInformation.GetProperty()
Mark Mc Mahon added the comment: I have added tests to the patch - but it's not easy to know what would cause an error in MsiSummaryInfoGetProperty which would trigger the new code. -- keywords: +patch Added file: http://bugs.python.org/file22165/ensure_MsiSummaryInfoGetProperty_return_value_checked.patch ___ Python tracker <http://bugs.python.org/issue12202> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3099] On windows, "import nul" always succeed
Mark Mc Mahon added the comment: I am not sure that I fully understand the issue - but it seems that trunk still has this issue. As stated by Amaury - this is on DEBUG builds only. c:\>pcbuild\python_d.exe Python 3.3a0 (default, May 28 2011, 20:22:11) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import nul [60967 refs] >>> import con ^Z [60986 refs] c:\>PCbuild\python.exe Python 3.3a0 (default, May 28 2011, 20:25:13) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import nul Traceback (most recent call last): File "", line 1, in ImportError: DLL load failed: The parameter is incorrect. >>> import con Traceback (most recent call last): File "", line 1, in ImportError: DLL load failed: The specified module could not be found. >>> -- nosy: +markm ___ Python tracker <http://bugs.python.org/issue3099> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12239] msilib VT_EMPTY SummaryInformation properties raise an error (suggest returning None)
New submission from Mark Mc Mahon :
Using "some.msi" where the first property is VT_EMPTY
Using COM:
>>> from win32com.client import gencache
>>> com_lib = gencache.EnsureModule('{000C1092---C000-0046}',
>>> 409, 1, 0)
>>> com_msi = com_lib.Installer()
>>> db = com_msi.OpenDatabase('some.msi', 0)
>>> si = db.GetSummaryInformation(0)
>>> repr(si.Property(0))
'None'
Using msilib:
>>> import msilib
>>> db = msilib.OpenDatabase(r'some.msi', 0)
>>> si = db.GetSummaryInformation(0)
>>> si.GetProperty(0)
Traceback (most recent call last):
File "", line 1, in
NotImplementedError: result of type 0
I aim to submit a patch that so that SummaryInformation.GetProperty() with a
type of VT_EMPTY will return None.
--
components: Windows
messages: 137478
nosy: markm
priority: normal
severity: normal
status: open
title: msilib VT_EMPTY SummaryInformation properties raise an error (suggest
returning None)
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue12239>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12239] msilib VT_EMPTY SummaryInformation properties raise an error (suggest returning None)
Changes by Mark Mc Mahon : -- keywords: +patch Added file: http://bugs.python.org/file22332/support_vt_empty_in_summary_getproperty.patch ___ Python tracker <http://bugs.python.org/issue12239> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9035] os.path.ismount on windows doesn't support windows mount points
Mark Mc Mahon added the comment: I was looking at this - and see that (at least as far as GetFileAttributes is concerned) that a mount and a linked directory are seen the same... Here are some tests using ctypes # mounted drive >>> hex(windll.kernel32.GetFileAttributesW(ur"c:\temp\test_c_mount")) '0x410' # normal directory >>> hex(windll.kernel32.GetFileAttributesW(ur"c:\temp\orig")) '0x10' # link (created via mklink /d c:\temp\orig c:\temp\here2 >>> hex(windll.kernel32.GetFileAttributesW(ur"c:\temp\here2")) '0x410' On futher searching - I found the following link: http://msdn.microsoft.com/en-us/library/aa363940%28v=vs.85%29.aspx So the function ismount will need to do the following a) Get the file attributes b) check that it's a directory and is a reparse point c) Use FindFirstFile (and FindNextFile? - I need to test more) to fill in WIN32_FIND_DATA.dwResearved0 d) Check that against IO_REPARSE_TAG_MOUNT_POINT (0xA003) -- ___ Python tracker <http://bugs.python.org/issue9035> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12382] [msilib] Obscure exception message when trying to open a non-existent MSI database
Mark Mc Mahon added the comment: The following two error conditions that can be returned by MsiOpenDatabase do not have specific handling: ERROR_CREATE_FAILED (1631) The database could not be created. ERROR_OPEN_FAILED (110) The database could not be opened as requested. (the messages are those copied from MSDN). Should extra cases for these go into the case statement in msierror? or should they be handled directly in OpenDatabase. Does the error text above sound OK - should we add ": '%s'" % msi_file ? -- nosy: +markm ___ Python tracker <http://bugs.python.org/issue12382> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11253] autodocument first appearance of ctypes.wintypes constants
Mark Mc Mahon added the comment:
This mostly a documentation concern - correct? ctypes.wintypes is sparsely
documented - in 2.7 the help for it seems to be:
"The ctypes.wintypes module provides quite some other Windows specific data
types, for example HWND, WPARAM, or DWORD. Some useful structures like MSG or
RECT are also defined."
How about the following solution:
First of all get the previous release information
- hg log / hg revert / import wintypes / dir(wintypes)
Future changes have to be updated manually (which probably is not a big deal as
it is a reasonably stable module)
In fact I went and got the revision when each attribute was added... (some of
those are just ctypes leakage)
{36899: ['ARRAY', 'MSG',
'ArgumentError', 'OLESTR',
'Array', 'OleDLL',
'BOOL','POINT',
'BYTE','POINTER',
'BigEndianStructure', 'POINTL',
'DEFAULT_MODE','PYFUNCTYPE',
'DWORD', 'PyDLL',
'FILETIME','RECT',
'FormatError', 'RECTL',
'GetLastError','RGB',
'HANDLE', 'RTLD_GLOBAL',
'HDC', 'RTLD_LOCAL',
'HGDIOBJ', 'SIZE',
'HINSTANCE', 'SIZEL',
'HKEY','SetPointerType',
'HMENU', 'Structure',
'HMODULE', 'ULARGE_INTEGER',
'HPEN','ULONG',
'HRESULT', 'Union',
'HRGN','VARIANT_BOOL',
'HTASK', 'WIN32_FIND_DATAA',
'HWND','WIN32_FIND_DATAW',
'LARGE_INTEGER', 'WINFUNCTYPE',
'LCID','WORD',
'LONG','WPARAM',
'LPARAM', 'WinDLL',
'LPCOLESTR', 'WinError',
'LPCSTR', 'alignment',
'LPCWSTR', 'get_errno',
'LPOLESTR','get_last_error',
'LPSTR', 'resize',
'LPWSTR', 'set_conversion_mode',
'LibraryLoader', 'set_errno',
'LittleEndianStructure', 'set_last_error',
'MAX_PATH',]
38788: ['ATOM', 'HRSRC',
'BOOLEAN', 'HSTR',
'COLORREF', 'HWINSTA',
'HACCEL', 'LANGID',
'HBITMAP', 'LCTYPE',
'HBRUSH', 'LGRPID',
'HCOLORSPACE', 'SC_HANDLE',
'HDESK','SERVICE_STATUS_HANDLE',
'HDWP', 'SMALL_RECT',
'HENHMETAFILE', '_COORD',
'HFONT','_FILETIME',
'HGLOBAL', '_POINTL',
'HHOOK','_RECTL',
'HICON','_SMALL_RECT',
'HKL', 'tagMSG',
'HLOCAL', 'tagPOINT',
'HMETAFILE','tagRECT',
'HMONITOR', 'tagSIZE',
'HPALETTE',]
38830: ['DOUBLE',
'UINT',
'WCHAR',
'_LARGE_INTEGER',
'_SimpleCData',
'_ULARGE_INTEGER',
'__all__'],
48320: ['FLOAT',
'INT',
'LPCVOID',
'LPVOID',
'SHORT',
'USHORT']}
48320 -> 2.7?
38830 -> 2.5?
38788 -> 2.5?
36899 -> 2.4?
So we need a doc patch? Should we update the older 'What's new in Python 2.x'
for added attribs?
--
nosy: +markm
___
Python tracker
<http://bugs.python.org/issue11253>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8554] suspicious comment in msilib.py/__init__.py
Mark Mc Mahon added the comment:
Per: http://msdn.microsoft.com/en-us/library/aa369212(v=vs.85).aspx
"""The Identifier data type is a text string. Identifiers may contain the
ASCII characters A-Z (a-z), digits, underscores (_), or periods (.). However,
every identifier must begin with either a letter or an underscore."""
So the spec would say that colons are NOT allowed. Editing some entries in the
File table of an MSI (using Orca from the MSI SDK) and running the validation
confirms that.
All the following were flagged as errors during validation:
'KDiff3EXE;"ASDF@#$', 'chmFile-', 'pdfFile(', 'hgbook]', 'TortoisePlinkEXE]',
'Hg.Cämd', 'merg:epatterns.rc'
I think that this issue should be fixed when issue2694 is fixed. (I would like
to put together some tests and patch for that :)
--
nosy: +markm
___
Python tracker
<http://bugs.python.org/issue8554>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2694] msilib file names check too strict ?
Mark Mc Mahon added the comment:
How about the following patch and tests...
Per: http://msdn.microsoft.com/en-us/library/aa369212(v=vs.85).aspx
"""The Identifier data type is a text string. Identifiers may contain the
ASCII characters A-Z (a-z), digits, underscores (_), or periods (.). However,
every identifier must begin with either a letter or an underscore."""
So the spec would say that colons are NOT allowed. Editing some entries in the
File table of an MSI (using Orca from the MSI SDK) and running the validation
confirms that.
All the following were flagged as errors:
'KDiff3EXE;"ASDF@#$', 'chmFile-', 'pdfFile(', 'hgbook]', 'TortoisePlinkEXE]',
'Hg.Cämd'
I also did some speed testing (just in case non/regex might be slow)
Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from timeit import timeit
>>> setup = 'import string\nidentifier_chars = string.ascii_letters +
>>> string.digits + "._"\ntmp_str = []'
>>> timeit("re.sub(r'[^a-zA-Z_\.]', '_', 'somefilename.txt')", setup = "import
>>> re")
4.434621757767205
>>> setup = 'import string\nidentifier_chars = string.ascii_letters +
>>> string.digits + "._"\ntmp_str = []'
>>> timeit('"".join([c if c in identifier_chars else "_" for c in
>>> "somefilename.txt"])', setup)
3.3757537425069906
>>>
--
keywords: +patch
nosy: +markm
Added file: http://bugs.python.org/file21408/make_id_fix_and_test.patch
___
Python tracker
<http://bugs.python.org/issue2694>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1128] msilib.Directory.make_short only handles file names with a single dot in them
Mark Mc Mahon added the comment:
I looked at the existing patches - and noted that they went closer to how
Windows does short files - but still left out some cases.
I believe the latest patch catches all cases.
from http://msdn.microsoft.com/en-us/library/aa368590(v=vs.85).aspx
Short and long file names must not contain the following characters:
slash (/) or (\)
question mark (?)
vertical bar (|)
right angle bracket (>)
left angle bracket (<)
colon (:)
asterisk (*)
quotation mark (")
In addition, short file names must not contain the following characters:
plus sign (+)
comma (,)
semicolon (;)
equals sign (=)
left square bracket ([)
right square bracket (])
No space is allowed preceding the vertical bar (|) separator for the short
file name/long file name syntax. Short file names may not include a space,
although a long file name may. A space can exist after the separator only if
the long file name of the file name begins with the space. No full-path syntax
is allowed.
Though I wonder do we really need to check for or replace the first set of
characters above - none are allowed in any file name, so if they are there it
is probably a error in how the function was called!
I also tested speed of re.sub, comprehension ("".join(c for c in ...) and for
loops - and for loops were the fasted (for the small set of characters being
replaced).
I am not patching make_id() - because I have added a patch for that to
issue2694.
Note - The attached patch will probably not apply cleanly - as it pre-supposes
that the patch (http://bugs.python.org/file21408/make_id_fix_and_test.patch)
from issue2694 is applied first (especially for the tests)
--
nosy: +markm
Added file: http://bugs.python.org/file21420/msilib.make_short.patch
___
Python tracker
<http://bugs.python.org/issue1128>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7639] bdist_msi fails on files with long names
Mark Mc Mahon added the comment: Following up from my comment in issue1128, please find the patch msilib.make_id_fix_and_tests.patch This improves the make_id() function in the following way: - ensures that NO invalid identifier characters make it through (it does this by only including good characters rather than filtering out some bad characters). The list of bad characters is immense (most unicode characters!) while the list of acceptable characters is limited. This also adds some tests. -- nosy: +markm -python-dev Added file: http://bugs.python.org/file21425/msilib.make_id_fix_and_tests.patch ___ Python tracker <http://bugs.python.org/issue7639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7639] bdist_msi fails on files with long names
Mark Mc Mahon added the comment: For Directory.make_short() the only things which are left could be considered splitting hairs. 1. Do we need to remove '"\/:' from the file name - if these characters are there then the file name is not valid in the first place. 2. These characters '+,;=[]' should really be changed to '_' if we want to match more closely how Windows makes short names. I can write a patch for the above if they should be fixed and either way I can add tests for this function. (the test I had for testing my own patch - almost completely pass - but the only failure was depending on point 2.) -- ___ Python tracker <http://bugs.python.org/issue7639> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11696] msilib.make_id() is not safe for non ASCII characters.
New submission from Mark Mc Mahon : msilib.make_id() currently ensure that any of the following characters are not in the resulting ID: " -+~;" Per the Microsoft documentation the following list of characters are allowed. http://msdn.microsoft.com/en-us/library/aa369212(v=vs.85).aspx """The Identifier data type is a text string. Identifiers may contain the ASCII characters A-Z (a-z), digits, underscores (_), or periods (.). However, every identifier must begin with either a letter or an underscore.""" If an file name contains any characters outside of the characters " -+~;" + string.ascii_letters + string.digits + "._" then it will be an invalid ID. This includes many punctuation characters which are valid in file names but not ID's, and every unicode character which does not overlap with ASCII. The attached patch tries to fix this - and it includes tests. -- components: Windows files: msilib.make_id_fix_and_tests2.patch keywords: patch messages: 132336 nosy: markm priority: normal severity: normal status: open title: msilib.make_id() is not safe for non ASCII characters. versions: Python 3.2 Added file: http://bugs.python.org/file21430/msilib.make_id_fix_and_tests2.patch ___ Python tracker <http://bugs.python.org/issue11696> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11702] dir on return value of msilib.OpenDatabase() crashes python
New submission from Mark Mc Mahon :
Running the following code:
>>> import msilib
>>> db = msilib.OpenDatabase('c:/windows/installer/1c7a1.msi', 1)
>>> db
<_msi.Database object at 0x01E230A0>
>>> dir(db)
(Python crashes - tested on current Trunk and Python 2.7.1).
I tried tracking it through the C code - and it seems to be a problem when dir
is checking for __dir__ (the pointer in PyObject_GetAttrString seems to be
incorrect).
--
components: Windows
messages: 132402
nosy: markm
priority: normal
severity: normal
status: open
title: dir on return value of msilib.OpenDatabase() crashes python
type: crash
versions: Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue11702>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11702] dir on return value of msilib.OpenDatabase() crashes python
Mark Mc Mahon added the comment: That fixed it - but it seems we need that for the other Types defined in the module. Regarding testing - would it be a good idea to add an MSI to the test suite - or better to create one during testing (using msilib) and then use that in the tests? -- Added file: http://bugs.python.org/file21466/msi_opendatabase_2.patch ___ Python tracker <http://bugs.python.org/issue11702> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2694] msilib file names check too strict ?
Mark Mc Mahon added the comment: This issue has been fixed by changes made in issue7639 and issue11696 -- ___ Python tracker <http://bugs.python.org/issue2694> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8554] suspicious comment in msilib.py/__init__.py
Mark Mc Mahon added the comment: This issue has been fixed when issue11696 was fixed. -- ___ Python tracker <http://bugs.python.org/issue8554> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character
Mark Mc Mahon added the comment: I have updated the patch for current trunk (though no real changes required). I also include a testcase. One thing to review is that I added functionality to the tests to create the MSI to be tested. (felt this was safer than touching one of the ones under %systemroot%\installer. -- keywords: +patch nosy: +markm Added file: http://bugs.python.org/file21524/issue1104_msi_2.patch ___ Python tracker <http://bugs.python.org/issue1104> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character
Mark Mc Mahon added the comment: And fix the typo... (thanks Ezio) -- Added file: http://bugs.python.org/file21525/issue1104_msi_3.patch ___ Python tracker <http://bugs.python.org/issue1104> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11834] wrong module installation dir on Windows
Mark Mc Mahon added the comment: Reviewing the patch (issue133572.py33.patch): You have used forward slashes for the first change - but back slashes for the others. I see that other places in the existing docs use back slashes when referring to windows paths. I have never used the --prefix option - but I am surprised that it would install scripts to prefix\Lib\site-packages (without the prefix option scripts are installed in pythondir\Scripts. Maybe installing something like grin/pylint/etc which has an executable script is a way to verify? -- nosy: +markm ___ Python tracker <http://bugs.python.org/issue11834> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12026] Support more of MSI api by exposing handles
New submission from Mark Mc Mahon : Background: My main use case for msilib is for working with/editing existing MSI files and not creating MSI files. As such I find much of the MSI API that I need missing. While not difficult to re-create _msi.c with ctypes, I thought it might be good to use as much of _msi.c as implemented (faster :) ) Patch: The patch exposes the 'h' member of msiobj as 'handle', and updates the doc to refer to them. There are no tests in the patch yet. Any recommendation on tests? (just check that the member exists and has an 'int' value? -- components: Library (Lib) files: expose_msi.c_handles.diff keywords: patch messages: 135401 nosy: loewis, markm priority: normal severity: normal status: open title: Support more of MSI api by exposing handles type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file21914/expose_msi.c_handles.diff ___ Python tracker <http://bugs.python.org/issue12026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12026] Support more of MSI api by exposing handles
Mark Mc Mahon added the comment: You can pass it to any function in the MSI SDK through ctypes. e.g. def ReadStream(record, field): buf = (ctypes.c_char * 2048)() orig_size = ctypes.sizeof(buf) status = 0 res = [] while status == 0: size = ctypes.c_long(ctypes.sizeof(buf)) status = msidll.MsiRecordReadStream( record.hanlde, field, ctypes.byref(buf), ctypes.byref(size)) res.append(buf.raw) if size.value != orig_size: break data = "".join(res) return data or any of the other functions not currently implemented in _msi.c Some of the other important ones (to me at least) are: - MsiDatabaseGetPrimaryKeys - MsiDatabaseExport - MsiDatabaseImport If the whole MSI SDK is wrapped - then exposing the handles would have no use :). The alternative I have so far is to re-write _msi.c using ctypes (already done), but I thought it would be better if not all of _msi.c had to be re-implemented. One alternative patch is to include those extra functions in _msi.c (though I am not sure I have the C skills to achieve that easily - and it may still miss functionality, and it may have even less chance of being accepted) -- ___ Python tracker <http://bugs.python.org/issue12026> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11702] dir on return value of msilib.OpenDatabase() crashes python
Mark Mc Mahon added the comment: I wasn't so happy trawling through \windows\installer either :) Creating an MSI to test is very simple, and actually quicker than I had originally thought. The latest patch (support_dir_for_msi_objs.patch) creates the one and just uses that. Optionally I could create a new one each time setUp()/tearDown(). But was thinking - let's do that if/when we need to :) The latest patch updates the tests - but no change to the C code. (I doubt the error you received is a bug in msilib, and I couldn't repro even by opening EVERY MSI in my windows\installer dir. It could be a rights/security issue? The previous test was not opening as READ ONLY - even though it never saved the db, so that may be another reason?) -- Added file: http://bugs.python.org/file22043/support_dir_for_msi_objs.patch ___ Python tracker <http://bugs.python.org/issue11702> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
