[issue11253] autodocument first appearance of ctypes.wintypes constants

2011-06-26 Thread Mark Mc Mahon
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 u

[issue12382] [msilib] Obscure exception message when trying to open a non-existent MSI database

2011-06-25 Thread Mark Mc Mahon
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

[issue9035] os.path.ismount on windows doesn't support windows mount points

2011-06-11 Thread Mark Mc Mahon
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(u

[issue12239] msilib VT_EMPTY SummaryInformation properties raise an error (suggest returning None)

2011-06-11 Thread Mark Mc Mahon
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/issue12

[issue12239] msilib VT_EMPTY SummaryInformation properties raise an error (suggest returning None)

2011-06-02 Thread Mark Mc Mahon
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,

[issue3099] On windows, "import nul" always succeed

2011-05-28 Thread Mark Mc Mahon
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 wi

[issue12202] Check status returns in msilib.SummaryInformation.GetProperty()

2011-05-28 Thread Mark Mc Mahon
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/file

[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character

2011-05-28 Thread Mark Mc Mahon
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 (i

[issue12202] Check status returns in msilib.SummaryInformation.GetProperty()

2011-05-28 Thread Mark Mc Mahon
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. -- mes

[issue12201] Returning FILETIME is unsupported in msilib.SummaryInformation.GetProperty()

2011-05-28 Thread Mark Mc Mahon
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

[issue11702] dir on return value of msilib.OpenDatabase() crashes python

2011-05-20 Thread Mark Mc Mahon
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. Optiona

[issue12026] Support more of MSI api by exposing handles

2011-05-08 Thread Mark Mc Mahon
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

[issue12026] Support more of MSI api by exposing handles

2011-05-06 Thread Mark Mc Mahon
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

[issue11834] wrong module installation dir on Windows

2011-04-26 Thread Mark Mc Mahon
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

[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character

2011-04-03 Thread Mark Mc Mahon
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/issue1

[issue1104] msilib.SummaryInfo.GetProperty() truncates the string by one character

2011-04-03 Thread Mark Mc Mahon
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

[issue8554] suspicious comment in msilib.py/__init__.py

2011-03-29 Thread Mark Mc Mahon
Mark Mc Mahon added the comment: This issue has been fixed when issue11696 was fixed. -- ___ Python tracker <http://bugs.python.org/issue8554> ___ ___ Python-bug

[issue2694] msilib file names check too strict ?

2011-03-29 Thread Mark Mc Mahon
Mark Mc Mahon added the comment: This issue has been fixed by changes made in issue7639 and issue11696 -- ___ Python tracker <http://bugs.python.org/issue2

[issue11702] dir on return value of msilib.OpenDatabase() crashes python

2011-03-29 Thread Mark Mc Mahon
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

[issue11702] dir on return value of msilib.OpenDatabase() crashes python

2011-03-28 Thread Mark Mc Mahon
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 T

[issue11696] msilib.make_id() is not safe for non ASCII characters.

2011-03-27 Thread Mark Mc Mahon
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).a

[issue7639] bdist_msi fails on files with long names

2011-03-27 Thread Mark Mc Mahon
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. T

[issue7639] bdist_msi fails on files with long names

2011-03-27 Thread Mark Mc Mahon
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

[issue1128] msilib.Directory.make_short only handles file names with a single dot in them

2011-03-26 Thread Mark Mc Mahon
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

[issue2694] msilib file names check too strict ?

2011-03-26 Thread Mark Mc Mahon
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 perio

[issue8554] suspicious comment in msilib.py/__init__.py

2011-03-26 Thread Mark Mc Mahon
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 begi