-
Notifications
You must be signed in to change notification settings - Fork 527
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add OpenOptions
to windows-registry
#3461
Conversation
This example would be great in the README (so it shows up in the crate documentation on docs.rs). |
Done - thanks for the suggestion! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a really nice API! The extensibility is a nice feature too as it'll make future feature requests much easier to accommodate.
@riverar - good feedback but I'd rather not add features opportunistically. If and when such needs present themselves, we can now more easily introduce them. |
Co-authored-by: Rafael Rivera <[email protected]>
Rather than adding more registry creation methods to satisfy #3269, #3346, or any future needs, this update introduces an
OpenOptions
type modeled afterstd::fs::OpenOptions
. This new type provides the options and flags that you can set in order to configure how a registry key is opened. TheKey
type continues to provide thecreate
andopen
methods as a convenience but internally they now also useOpenOptions
for construction. Let's consider a few examples.Today you can use
create
to create or open a registry key for read and write access:What if you only want to open the key if it already exists? Well you can use
open
instead but it offers only read access:This is where you can use the new
options
method to gain more control:This opens the subkey with write access but only if it already exists. The call will fail if the key does not exist. Want to create the key in all cases? Just set the
create
option:You can also optionally create a
Transaction
object for transactional access to the registry:Failure to commit the transaction will cause all changes to be rolled back when the transaction object is dropped. They are also not observable outside of the transaction until and unless
commit
is called.Finally, I removed the
Default
implementation from theKey
object. This just seemed confusing as you could try (and fail) to use the various registry functions on an invalid registry key handle. If for some reason you need to hold on to an invalid registry key you can still use the unsafefrom_raw
method.Fixes: #3269
Fixes: #3346