search

MrPig91 / PSChiaPlotter

A repo for powershell module that helps Chia Plotting
MIT License
182 stars 47 forks source link

unable to see NVME drive and Ramdrive also Drive on network #165

Open yanadhorn opened 3 years ago

yanadhorn commented 3 years ago

unable to see NVME drive and Ramdrive also Drive on network

MrPig91 commented 3 years ago

I am sorry PSChiaPlotter is not picking up all your drives. Are you able to use the UNC path to the drives/folders in the basic plotting section? I know this isn't ideal but is currently the easiest workaround.

yanadhorn commented 3 years ago

I am sorry PSChiaPlotter is not picking up all your drives. Are you able to use the UNC path to the drives/folders in the basic plotting section? I know this isn't ideal but is currently the easiest workaround.

i will try and let you know. but it is weird that it is not see my Plotter Drive (Wd Black m,2 nvme that it is in stall on my plotter not on the network.

Jacek-ghub commented 3 years ago

@yanadhorn

Could you run in Power Shell the following commands and provide results from them:

  Get-Volume
  Get-Partition
  Get-Partition | Where {$_.AccessPaths.Count -gt 1}

Those are commands that PSChiaPlotter is using to check on available partitions. The fact that it is WD Black doesn't really matter, as people are using all kind of drives, and so far that was not an issue, so it has to be rather something related to how you added that NVMe to your system (potentially format type, etc.) making it prepared in a way that PSCP barfs at it. (You can filter out everything that is not related to your NVMe drive.)

Actually, your PSCP version would be helpful.

By the way, I have WD Black 1TB NVMe on my system, and it works like a charm.

RamsesDeux commented 3 years ago

@yanadhorn

Could you run in Power Shell the following commands and provide results from them:

  Get-Volume
  Get-Partition
  Get-Partition | Where {$_.AccessPaths.Count -gt 1}

Those are commands that PSChiaPlotter is using to check on available partitions. The fact that it is WD Black doesn't really matter, as people are using all kind of drives, and so far that was not an issue, so it has to be rather something related to how you added that NVMe to your system (potentially format type, etc.) making it prepared in a way that PSCP barfs at it. (You can filter out everything that is not related to your NVMe drive.)

Actually, your PSCP version would be helpful.

By the way, I have WD Black 1TB NVMe on my system, and it works like a charm.

Well, funny enough I do have the same issue.

And its a powershell issue not having access to network mapped drives while CMD.exe and Explorer do!

I haven't find any solution to this for now. Will update you guys if I do.

Jacek-ghub commented 3 years ago

@ramsesdeux

I guess, Google is your friend. I did a quick search, and maybe the issue is that you are running PowerShell as Admin, where you mapped that drive as a "normal" user.

RamsesDeux commented 3 years ago

@ramsesdeux

I guess, Google is your friend. I did a quick search, and maybe the issue is that you are running PowerShell as Admin, where you mapped that drive as a "normal" user.

Exactly that. I've done so research and the issue lies in here.

That's it guys: When create network drives, do so in a promoted shell. Or modify your registry so that all network drives for all account are linked ;) http://woshub.com/how-to-access-mapped-network-drives-from-the-elevated-apps/

(hope it is ok to share links?)

Jacek-ghub commented 3 years ago

@ramsesdeux

Or maybe you should not run the program with the elevated privileges? This is a bit easier solution, as it doesn't require any extra steps.

@MrPig91

Here is MS blog about checking for elevated privileges: https://devblogs.microsoft.com/scripting/check-for-admin-credentials-in-a-powershell-script/

Maybe it would be good to check at startup for those, and if elevated, then just barf?

MrPig91 commented 3 years ago

@Jacek-ghub

Great idea. This should be easy to implement. I will add confirm prompt when it detects running with elevated privileges before launching the GUI.

Jacek-ghub commented 3 years ago

@MrPig91

What I meant was to rather abort PSCP, when elevated privileges are detected (yes, after a warning prompt).

Unless you can find one, and I mean one reason to run at elevated privileges, there is no point to have it run. This is just one of the issues related to those privileges, and it may be more, and more subtle ones, i.e., harder to nail down.

I guess, consider the old saying that your software should always be foolproof. If a feature has no obvious benefits (e.g., running with elevated privileges), then cut it off, not just warn end-users that shit may still happen at some point.

If people will have problem with that, they will voice it here, and it will be easier to address those problems.