Jump to content

- - - - -

Data loss when unmounting without administrative privileges

  • Please log in to reply
3 replies to this topic

#1 v77


    Silver Member

  • Team Reboot
  • 590 posts

Posted 12 October 2019 - 12:24 PM

This is likely the more important remaining issue of ImDisk.
A user of ProxyCrypt reported various data losses related to the fact he did not dismount the volume with administrative privileges:

When I initially written ImDisk Toolkit, I modified the drive letter context menu to make sure all operations were elevated. I did that to fix the issue of remaining volumes in "imdisk -l", and it worked so far.
As a side effect, it also fixed the risk of data loss, at least as long as the user does not directly use the control panel applet.

For ProxyCrypt, I also can recommend to use the Toolkit, but for users who are looking for a minimalist and/or portable solution, it may not be the best choice.

Of course, we need to leave a possibility for those who want to lose their data, for instance with the command line tool.
But for the control panel, I think we should find a way to auto-elevate it. I just saw that using "requireAdministrator" in a (external) manifest does not work. But it should be possible to use ShellExecute with "runas" as verb in the default entry point.



Another point. You use DBT_DEVICEQUERYREMOVE as first notification. But we are supposed to be able to return BROADCAST_QUERY_DENY.
However, as you use SendMessageTimeout with HWND_BROADCAST, I wonder how you could take this return value into account.

This notification seems useless if we cannot respond to it.
If I was able to stop the volume unmount with that, I would have a way to let ProxyCrypt do the unmount properly...

#2 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1433 posts
  • Location:Borås, Sweden

Posted 15 October 2019 - 03:01 PM

Yes, I agree, the Control Panel applet should really make sure that it runs with elevated privileges. I am not really sure how other applets usually do this, but I'll try your suggestion. I am not entirely sure that it is possible to solve in that particular way though since it is not possible to open a Control Panel twice, but I'll check if there is a workaround somehow. It could of course be a better choice to use an exe for the actual dialog in some way too.

#3 v77


    Silver Member

  • Team Reboot
  • 590 posts

Posted 15 October 2019 - 03:32 PM

it is not possible to open a Control Panel twice


It's possible from Explorer, in the System32 folder. First, start it by double-clicking it, and then, use the context menu with "Run as administrator". You will get 2 windows of imdisk.cpl.
Don't know if this can be reproduced programmatically.

#4 v77


    Silver Member

  • Team Reboot
  • 590 posts

Posted 15 October 2019 - 04:58 PM

By the way, it seems I just found out a new bug in the system.

When I try to create programmatically a shortcut to imdisk.cpl with the IShellLink interface, the icon is set by default to an icon of the system.
So I change it by using SetIconLocation. I save all that and it works... as long as I use an icon index different of 0.
With the index 1, I can see directly the second icon of imdisk.cpl.
With the index 0, I see an icon of the system. If I use the Explorer's dialog box, I can see that both the location and the index are properly selected. Then I click OK, and the icon is properly updated.

If I make a copy of the .lnk file before the update with Explorer, I can see that Explorer changes the content of the .lnk file.
Now, if I import the 2 .lnk files in another system (with imdisk installed), the non-updated .lnk file continues to show a wrong icon.

So, this is not an issue of the running shell, such as a cache not updated. It's IShellLink that not properly construct the .lnk file if the icon index is 0.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users