[PUP-7888] Pluginsync modules with deep directories fail on Windows Created: 2017/08/29  Updated: 2018/11/30

Status: Open
Project: Puppet
Component/s: Windows
Affects Version/s: PUP 4.7.1, PUP 5.1.0
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: Glenn Sarti Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Node: Windows 2012R2
Master: Using 2016.4.2 but it is not master dependant
Puppet 4.7.1 but will affect Puppet 5.1.0 too


Issue Links:
Relates
relates to MODULES-5550 Supported Release (puppetlabs-dsc) 1.... Resolved
relates to PUP-4866 Plug-in Sync Should Use Long File Nam... Accepted
Template:
Acceptance Criteria:
  • Should be able to sync a module with a resultant path length that exceeds 260 characters
Team: Coremunity
Method Found: Automated Test
CS Priority: Normal
CS Frequency: 2 - 5-25% of Customers
CS Severity: 3 - Serious
CS Business Value: 4 - $$$$$
CS Impact: It appears that there is a workaround for this by turning "NTFS long path support." in Server 2016. Unfortunately this is not an option in 2008 or 2012.

In those older versions there is no workaround so this prevents functionality for users who have long paths.
QA Risk Assessment: Needs Assessment

 Description   

After updating the Windows DSC module with the latest resources, the acceptance tests were failing setup due to plugin cache failing to synchronise files with deep directories

$ puppet agent -t --trace
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Error: Could not set 'file' on ensure: No such file or directory @ dir_s_mkdir - C:/ProgramData/PuppetLabs/puppet/cache/lib/puppet_x/dsc_resources/xSQLServer/DSCResources/MSFT_xSQLServerAlwaysOnAvailabilityGroupDatabaseMembership/en-US/MSFT_xSQLServerAlwaysOnAvailabilityGroupDatabaseMembership.strings.psd120170829-2800-rxsfcz.lock
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/file_system/uniquefile.rb:182:in `mkdir'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/file_system/uniquefile.rb:182:in `mkdir'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/file_system/uniquefile.rb:175:in `locking'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/file_system/uniquefile.rb:38:in `block in initialize'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/file_system/uniquefile.rb:134:in `create_tmpname'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/file_system/uniquefile.rb:28:in `initialize'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/util.rb:453:in `new'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/util.rb:453:in `replace_file'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/type/file.rb:854:in `write'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/type/file/data_sync.rb:87:in `contents_sync'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/type/file/content.rb:121:in `sync'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/type/file/ensure.rb:66:in `block (2 levels) in <module:Puppet>'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/property.rb:487:in `set'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/property.rb:561:in `sync'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/type/file/ensure.rb:186:in `sync'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:236:in `sync'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:134:in `sync_if_needed'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:80:in `perform_changes'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:21:in `evaluate'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/transaction.rb:224:in `apply'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/transaction.rb:240:in `eval_resource'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/transaction.rb:163:in `call'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/transaction.rb:163:in `block (2 levels) in evaluate'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/util.rb:386:in `block in thinmark'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/2.1.0/benchmark.rb:294:in `realtime'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/util.rb:385:in `thinmark'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/transaction.rb:163:in `block in evaluate'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/graph/relationship_graph.rb:118:in `traverse'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/transaction.rb:154:in `evaluate'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/resource/catalog.rb:222:in `block in apply'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/util/log.rb:159:in `with_destination'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/transaction/report.rb:137:in `as_logging_destination'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/resource/catalog.rb:221:in `apply'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/configurer/downloader.rb:13:in `evaluate'
C:/Program Files/Puppet Labs/Puppet/sys/ruby/lib/ruby/vendor_ruby/puppet/configurer/plugin_handler.rb:20:in `download_plugins'

It appears that the ruby mkdir function is hitting the MAX_PATH limit (https://msdn.microsoft.com/en-us/library/aa365247.aspx#maxpath)

Due to this failure we cannot update the DSC module with the SQL Server resources and it's only a matter of time until another module hits this issue.

Instead perhaps puppet should use the UNC style naming which support 32,000 path lengths instead.



 Comments   
Comment by matthieu [ 2017/10/13 ]

Problem solved in windows 2016 which removes the max_path using the "enable NTFS long path support" GPO parameter (https://www.saotn.org/ntfs-long-paths-windows-server-2016-gpo/) .

Successfully compiled the xSQLServer 8.2 dsc module in puppetlabs/dsc and downloaded the module through puppet agent in a windows 2016 vm.

Comment by Glenn Sarti [ 2017/10/13 ]

matthieu Thankyou for the update!!

Generated at Mon Sep 23 12:51:52 PDT 2019 using JIRA 7.7.1#77002-sha1:e75ca93d5574d9409c0630b81c894d9065296414.