homepage

Attached is a patch that fixes the handling of file names with 0 or 2 or
more dots in them.

Sorry, I don't know how create a patch, but just change the line with 
parts = file.split(".") to parts = os.path.splitext(file)
and the problem is fixed.

I create a patch using the os.path.splitext function.

The current patch is not correct, because os.path.splitext returns the
extension with the leading dot.
Here is another patch that simplifies the code (os.path.splitext is
guaranteed to return two strings)
It also adds the first unit test for msilib.
There is an unresolved issue: what is make_short('foo.2.txt') supposed
to return? FOO.2.TXT or FOO~1.TXT ?

@Amaury,
Sorry my mistake. I forgot splitext returns a tuple. =/
About your question, if the file name has less then 8 characters, then 
the function don't change it. Else, it return tha name with 8 chars.
e.g., make_short(foo.2.txt) returns FOO.2.TXT
and make_short(foo.longer_name.txt) returns FOO.LO~1.TXT

So what happens if the original file name is something like "foo~1.txt"? Couldn't there be a name collision?

Here's how Microsoft does it: http://support.microsoft.com/kb/142982/en-us 

MSI short names must be 8.3 names. Microsoft has them in MSI in case the MSI file gets installed on an 8.3 system, or in case 8.3 applications want to access files and want to be sure they access the right one. So the actual numbering is completely irrelevant (since we only support systems with long file name support, and will always use long names to access the files). They still need to be in the 8.3 space, though, else Installer might be unhappy. So having two dots in the short name is incorrect.

A slightly different patch is attached to issue7639, which generates short names more similar to Windows/NTFS:
 
http://bugs.python.org/file15898/msilib_make_short.diff
Here are some short names created with the msilib_make_short patch, which are identical to the short names created by the Windows NTFS file system:
foo.txt -> FOO.TXT
foo.2.txt -> FOO2~1.TXT
someLongName.txt -> SOMELO~1.TXT
someLongerName.txt -> SOMELO~2.TXT
For comparison, the msilib-2 patch generates these short names:
foo.txt -> FOO.TXT
foo.2.txt -> FOO.2.TXT <- different from NTFS
someLongName.txt -> SOMELO~1.TXT
someLongerName.txt -> SOMELO~2.TXT

@Brian/Tim do have have any input on this? Also note that a similar patch exists on issue7639.

The revised patch for issue7639 now generates better short names for file names containing spaces, '+', and leading '.'.
http://bugs.python.org/file19334/msilib.diff
Test cases that could be added to MsilibTest.test_makeshort():
TEST : test
TES~1.T : t.e.s.t
TEST~1 : .test
TESTTEST : testtest
TESTTE~1 : .testtest
TESTTE~2 : test test
TESTTE~3 : test test test
AFILE~1.DOC : A file.doc
THISIS~1.TXT : This is a really long filename.123.456.789.txt
THISIS~1.789 : This is a really long filename.123.456.7890
TEST__~1 : test++
TE____~1 : te++++++
TEST~1.__ : test.++
TEST.123 : test.123
TEST~1.123 : test.1234
TEXT~1.123 : text.1234
TESTTE~1.__ : testtest.++
FOO.TXT : foo.txt
FOO2~1.TXT : foo.2.txt
SOMELO~1.TXT : someLongName.txt
SOMELO~2.TXT : someLongerName.txt
PY~15~1.~ : py.~1.5.~

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)

This is now fixed with Christoph Gohlke's patch in issue 7639. If anything remains to be done, please submit a new issue (rather than posting to this one).