MantisBT - CMake
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0010257CMakeCMakepublic2010-02-08 14:592016-01-21 17:29
ReporterKerry Bonin 
Assigned ToBill Hoffman 
PrioritynormalSeverityblockReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product VersionCMake-2-8 
Target VersionFixed in Version 
Summary0010257: Installer erasing windows PATH
DescriptionI've had two developers who just installed cmake-2.8.0-win32-x86.exe report (and show me) that installing (on XP SP2) w/ 'all users' and 'add to system path' selected resulted in their windows PATH environment variable ending up containing ONLY the cmake path - the previous path contents are missing.

If this isn't a fluke of our corporate install environment (I haven't tried recreating in clean VM, as I don't have one setup ATM...) I'd recommend a fast fix and release spin, as this (obviously) breaks windows machines...
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
duplicate of 0010169closed Bill Hoffman Installer overwrites path environment variable 
has duplicate 0010063closed  Windows installer destroys user path 
has duplicate 0009878closed David Cole Windows installer destroys user path 
has duplicate 0010282closed  CMake installer cleared the PATH variable 
has duplicate 0010359closed Bill Hoffman Windows installer PATH issue 
has duplicate 0011931closed David Cole Popup during installation: "Warning! PATH too long installer unable to modify PATH!" 
related to 0012875closed Kitware Robot Installer overwrites PATH environment variable 
related to 0014716closed Brad King CMake installer can't modify %PATH% if it's 'loo long'. 
related to 0015635closed Kitware Robot CPACK_NSIS_MODIFY_PATH has no affect on PATH variable 
Attached Filestxt cmake-eaten-path.txt (1,478) 2010-02-09 11:26
https://public.kitware.com/Bug/file/2852/cmake-eaten-path.txt
Issue History
Date ModifiedUsernameFieldChange
2010-02-08 14:59Kerry BoninNew Issue
2010-02-08 15:37Bill HoffmanNote Added: 0019481
2010-02-08 15:38Bill HoffmanStatusnew => assigned
2010-02-08 15:38Bill HoffmanAssigned To => Bill Hoffman
2010-02-08 15:54Kerry BoninNote Added: 0019483
2010-02-08 16:18Kerry BoninNote Added: 0019485
2010-02-08 17:29Bill HoffmanNote Added: 0019487
2010-02-09 11:26Kerry BoninFile Added: cmake-eaten-path.txt
2010-02-09 11:29Kerry BoninNote Added: 0019496
2010-02-09 13:54Bill HoffmanRelationship addedhas duplicate 0010063
2010-02-09 13:55Bill HoffmanRelationship addedhas duplicate 0009878
2010-02-09 13:56Bill HoffmanRelationship addedduplicate of 0010169
2010-02-09 14:10Bill HoffmanNote Added: 0019497
2010-02-09 14:10Bill HoffmanNote Added: 0019498
2010-02-09 14:32Kerry BoninNote Added: 0019499
2010-02-09 14:48Kerry BoninNote Edited: 0019499
2010-02-09 15:50Bill HoffmanNote Added: 0019502
2010-02-12 15:25Bill HoffmanRelationship addedhas duplicate 0010282
2010-03-03 11:50Bill HoffmanRelationship addedhas duplicate 0010359
2010-09-21 11:51David ColeNote Added: 0022290
2010-11-04 17:04David ColeNote Added: 0022864
2010-11-04 17:04David ColeStatusassigned => closed
2010-11-04 17:04David ColeResolutionopen => fixed
2011-03-17 13:44David ColeRelationship addedhas duplicate 0011931
2012-01-15 22:28David ColeRelationship addedrelated to 0012875
2014-02-03 16:05Brad KingRelationship addedrelated to 0014716
2015-06-29 13:19David ColeRelationship addedrelated to 0015635

Notes
(0019481)
Bill Hoffman   
2010-02-08 15:37   
We have had reports of this, but have NEVER been able to duplicate it... It just does not seem to happen to us. I am sort of at a loss of how to fix it if I can not reproduce it. Can you give me the full PATH before CMake kills it?
(0019483)
Kerry Bonin   
2010-02-08 15:54   
I have ONE of the paths that was erased (by a fluke, the developer had it onscreen in a DOS window). That said, I'd rather not publish the path of a corporate machine on a public mailing list (due to near but not completely zero security issue) - if you send a private email to my gmail account (kerrybonin@gmail.com), I'll reply with the path...
(0019485)
Kerry Bonin   
2010-02-08 16:18   
The developer has sent me her paths (all users and user), just waiting for an email to send them to now...
(0019487)
Bill Hoffman   
2010-02-08 17:29   
Attach it to this bug with the upload file button.
(0019496)
Kerry Bonin   
2010-02-09 11:29   
I've attached the file - some information related to corporate environment redacted, alphas replaced w/ 'x', all other syntax preserved. This should allow an attempt at reproducing just about any issue related to syntax and parsing. I'd also be happy to test any fixes on a machine that previously had its path reliably eaten, please let me know...
(0019497)
Bill Hoffman   
2010-02-09 14:10   
OK, I have reproduced and found a fix of sorts.

$ cvs commit -m "Fix for bug 0010257, NSIS could remove a PATH if it was too long" NSIS.template.in
Committer: Bill Hoffman <bill.hoffman@kitware.com>
/cvsroot/CMake/CMake/Modules/NSIS.template.in,v <-- NSIS.template.in
new revision: 1.42; previous revision: 1.41

It will now warn if the PATH is long and NOT modify the PATH at all in this case.
(0019498)
Bill Hoffman   
2010-02-09 14:10   
I will put this fix into the next RC for CMake 2.8.1
(0019499)
Kerry Bonin   
2010-02-09 14:32   
(edited on: 2010-02-09 14:48)
I read up some on this issue, which apparently has been in NSIS for some time - the default build of NSIS has a string length of 1024 bytes, which results in broken paths. They also have a "special build" of NSIS that increases this global string limit to 8k bytes. For some reason (I can't find) this "feature" hasn't been turned on in their trunk.

I would like to request that cmake be packaged with this "special build" http://nsis.sourceforge.net/Special_Builds [^] to remove this bug. This is an optional build of their trunk, called 'strlen_8192', which I believe just defines a preprocessor macro NSIS_MAX_STRLEN=8192.
(0019502)
Bill Hoffman   
2010-02-09 15:50   
I will look into that. The fix that I did should work in that case as well. If you go over 8192 it will warn and do thing. I don't want to depend on this, and I want to make sure CMake never kills the path again.
(0022290)
David Cole   
2010-09-21 11:51   
Is this still a problem with 2.8.2 and the 2.8.3-rc1 release candidate?

Can we mark this as fixed, or is there still an issue here?
(0022864)
David Cole   
2010-11-04 17:04   
This was fixed in an earlier release of CMake (not sure if it was 2.8.1 or 2.8.2 or 2.8.3) -- if it rears its ugly head again, then please re-open and elaborate...