Feature store problems - Githubissues

dongle-the-gadget commented 2 years ago

For some reason, the /store parameter is unrecognized in 0.3.0, despite being listed in vivetool /enable /?.

> vivetool /enable /id:37010913 /store:both

ViVeTool v0.3.0 - Windows feature configuration tool

Unrecognized parameter: /store

Successfully set feature configuration(s)

The help documentation:

> vivetool /enable /?

ViVeTool v0.3.0 - Windows feature configuration tool

Syntax:
  /enable [...] [/store:<both | runtime | boot>]

[...]

Secondly, features are not added to the "boot" store, despite vivetool /enable /? saying it does.

> vivetool /enable /id:37010913

ViVeTool v0.3.0 - Windows feature configuration tool

Successfully set feature configuration(s)

> vivetool /query /store:runtime /id:37010913

ViVeTool v0.3.0 - Windows feature configuration tool

[37010913]
Priority        : Service (4)
State           : Enabled (2)
Type            : Experiment (1)

> vivetool /query /store:boot /id:37010913

ViVeTool v0.3.0 - Windows feature configuration tool

No configuration for feature ID 37010913 was found in the Boot store

> vivetool /enable /?

[...]

The parameters in square brackets don't need to be specified and will use these defaults:
  [...]
  Store             : Both

[...]

thebookisclosed commented 2 years ago

The writes do go to both stores by default, the selector not working is a very dumb oversight on my part. Like the /? info says, "Writing to the Boot store is necessary for features to persist across reboots. Changes to this store become effective the next time you reboot." Did you reboot between running /enable and /query?

dongle-the-gadget commented 2 years ago

I thought that changes would be saved, and there would be a way to view saved features. Query only lists features that are enabled?

thebookisclosed commented 2 years ago

Query talks to the Windows feature management API, the API caches Boot store contents when the system is starting up. Any changes made after that are present purely in registry. The tool output is made to resemble what Windows components see when they ask for a feature, letting the user view both active & inactive Boot overrides would involve a lot work.

dongle-the-gadget commented 2 years ago

Alright, so problem 2 is intended behavior of ViVeTool, whereas problem 1 is an oversight.

thebookisclosed commented 2 years ago

v0.3.1 is now out with problem 1 fixed. I additionally added extra text bits pointing out the Boot store behavior to hopefully reduce future confusion.