diff options
| author | Paul Berry <paul@puppetlabs.com> | 2011-03-08 11:35:58 -0800 |
|---|---|---|
| committer | Paul Berry <paul@puppetlabs.com> | 2011-03-08 13:04:39 -0800 |
| commit | 5ef10315705b8e4d69d13b8df86b9585f2bcc29a (patch) | |
| tree | 049e9d8343d023c7eea67103ce60d9bef9879960 /lib/puppet/util/rdoc/code_objects.rb | |
| parent | bd5517dd9cd8e10f488713d9654957746e687378 (diff) | |
| download | puppet-5ef10315705b8e4d69d13b8df86b9585f2bcc29a.tar.gz puppet-5ef10315705b8e4d69d13b8df86b9585f2bcc29a.tar.xz puppet-5ef10315705b8e4d69d13b8df86b9585f2bcc29a.zip | |
(#6632) Adding a new mount no longer causes error with umount
There were two problems:
* In lib/puppet/type/mount.rb, we were calling provider.mounted? to
determine whether we needed to execute "mount" after updating the
in-memory fstab record. This wasn't working properly because
provider.mounted? makes its decision based on the data stored in the
in-memory fstab record. Since the fstab record had just been
updated, provider.mounted? was incorrectly returning true even
though the device wasn't actually mounted. Fixed this by checking
provider.mounted? before updating the in-memory fstab record.
* Calling mount from this point in lib/puppet/type/mount.rb is
actually too early, because even though the in-memory fstab record
has been created, its contents have not been written to `/etc/fstab`
yet. Fixed this by storing a :needs_mount entry in the
property_hash and checking it at the end of the flush() method.
Reviewed-by: Jacob Helwig <jacob@puppetlabs.com>
Diffstat (limited to 'lib/puppet/util/rdoc/code_objects.rb')
0 files changed, 0 insertions, 0 deletions