xDiskAccessPath - Cannot re-create Access Path mapping about storagedsc HOT 17 CLOSED

Hi @Zuldan, awesome it is working OK (except for these glitches). I think I know what might be causing the problem - the resource is not correctly detecting that the partition has already been created, so is trying to create a new one (which reports that there is no capacity to add a new partition).

I'll put some work into writing some tests to confirm this this weekend and then create a fix (good old TDD methodology). 😁

from storagedsc.

Thank you very much @PlagueHO

from storagedsc.

@Zuldan - anytime sir! I ran out of time this weekend and tonight, but I'll get onto this tomorrow night. Hope that is OK?

from storagedsc.

No problem at all ;-)

from storagedsc.

Hi @Zuldan, I'm just working on adding tests for this scenario (so I can then write the fix) and have a question: when you say you delete the mount point: are you deleting the folder that the mount point was mounted to or are you unmounting the access path using a cmdlet or GUI? I'm just trying to write tests that replicate this behavior.

from storagedsc.

@PlagueHO I'm deleting the folder.

from storagedsc.

@Zuldan - Ok cool! I've managed to replicate it by using Remove-PartitionAccessPath to remove the mount. So, I've now got failing tests.

from storagedsc.

@Zuldan - making good progress on this. I have found the bug and just reworking the code to better support this use case. I'll try and get this PR through tomorrow night.

from storagedsc.

Cool! thanks for the update.

from storagedsc.

Hi @Zuldan - The code change is finished including integration/regression tests to cover this scenario. I've still got to complete the unit tests though - which I aim to complete tomorrow night.

If you're feeling enthusiastic you can try out the new version here in my fork.

from storagedsc.

@PlagueHO I can confirm it's now working as expected.

from storagedsc.

Awesome! Thanks @Zuldan. I was going to try and get the unit tests done tonight but I'm knackered and will just end up doing something dumb. So I'll get them done tomorrow night 😁

from storagedsc.

@kwirkykat - I'll include the conversion of the integration tests workspace folder over to $TestDrive in the PR for this issue. I need to include this because all my tests broke 😁

from storagedsc.

@kwirkykat - another question: Since the recent changes to PSSA checking (I'm not sure if it was a change to DSCResource.Tests or PSSA), but the WMI cmdlets that xDisk uses are being flagged as PSSA violations. So I can't submit the PR for this the xDiskAccessPath fix without resolving this.

xDisk uses CIM by default but falls back to WMI if that fails. I'm fairly sure we can remove the WMI calls safely, but someone must have added the fall back to WMI for a reason (unfortunately the comments don't say why this was done). So removing them may cause failures in earlier OS's.

So:
Option 1 - remove the WMI calls
Option 2 - suppress the WMI PSSA violations

What are your thoughts?

from storagedsc.

@Zuldan - I've completed the PR now and it just needs to go through the review process.

from storagedsc.

Thanks so much @PlagueHO. Apologies for the additional work this has created. The contribution of your personal time to the community is invaluable.

from storagedsc.

@Zuldan - always a pleasure! And this needed to be done. I'm actually much happier with the design pattern now as it handles many other scenarios. I'll be copying this design over to xDisk when I have the time because xDisk will suffer from the similar problems.

This new design will also better support the future "Destructive" flag to allow rewriting the partition table.

from storagedsc.