5 replies to this topic

[Morten Due Jørgensen]

Hi - I hope Olof reads this. :-)

 

I think I have found a bug in imdisk (2.0.9) - sorry, it was an accident.

 

I made a bat file with the following content:

 

imdisk.exe -a -s 40M -m R: -p "/fs:ntfs /q /y"

 

and I accidentally ran it from a non-elevated command prompt. It mounted the disk, but was denied access to formatting it. (When I looked in the control panel applet, the disk had no drive letter! This is different from what happens when you mount a disk using the applet.) Windows offered me to format the R: disk, but I declined, switched to en elevated command prompt, and ran the bat file again. This time I got the disk alright, it was formatted and assigned R: - which by the way is still the same letter as the first disk not displaying the letter. I then removed the FIRST disk in applet, but that ruined the SECOND disk as well!

 

It appears that there is some kind of mixup in this scenario. Fair enough I cannot format the disk, if I have not got the right to do so, but it should not destroy the second disk, when I remove the first, possibly through denying to create the second disk with the "same" drive letter.

 

Morten

 

[Olof Lagerkvist]

Hi.

 

First of all, I am a little bit surprised that the drive letter assigning did not work at your first try. People frequently mount ImDisk drives without administrative privileges and that should work. Formatting does not work in this way like you saw here because formatting fixed drives requires administrative privileges. You can workaround that by adding -o rem option to create a removable drive.

 

If you issue the same command again, you will get a new virtual disk with the same drive letter. This does not "destroy" the existing virtual disk, but it overwrites the drive letter assignment so you will not be able to access the old drive in any easy way without first assigning it a new drive letter. If you remove the second virtual disk the drive letter will also be removed and the old one will not automatically be assigned this drive letter.

 

You can then use for example my dosdev tool to assign a new drive letter to one of them in case the drive letter gets lost of overwritten in some way:

dosdev -r R: \Device\ImDisk0

(You can type imdisk -l for a list of currently mounted ImDisk drives.)

 

The problem with denying creation of a second virtual disk with the same drive letter as an existing would be that it would break some existing scripts and similar that do exactly this thing to reassign an existing drive letter to a new virtual disk. Of course I understand that this could also be done by mistake, but it does not destroy anything really. There are ways to get the drive letter assignment back.

[v77]

Olof, I think you missed something. He says: "Windows offered me to format the R: disk". This means that the drive letter assignment has worked. However, the control panel applet showed no drive letter: it's the first issue I see.
The second issue is that he removed the first volume, which had no drive letter, and the second was also unmounted.

So, the first time, the drive letter was not displayed in the applet, and the second time, this drive letter was used to remove R: (which means that it was properly stored).

I cannot reproduce the first issue, but I reproduced the second issue (on Windows 10). I removed the first drive, which had no drive letter because this one was redefined to the second, and the drive letter of the second drive has disappeared, both in the applet and in Explorer.

[Olof Lagerkvist]

Olof, I think you missed something. He says: "Windows offered me to format the R: disk". This means that the drive letter assignment has worked. However, the control panel applet showed no drive letter: it's the first issue I see.

That's how I read it too, from a more literal point of view. But I suppose he did not mean exactly that because this exact scenario seems rather unlikely to happen. If you use -m to specify a drive letter, that drive letter is saved by the driver and is shown in the Control Panel applet. Therefore I assumed that he meant that the drive letter was missing somewhere else. But I agree that the fact that Windows opened the "format new disk" dialog seems to contradict my guess though, thanks for pointing that out. I'm not entirely sure what could possibly have happened here really.
 

... I reproduced the second issue (on Windows 10). I removed the first drive, which had no drive letter because this one was redefined to the second, and the drive letter of the second drive has disappeared, both in the applet and in Explorer.

 
That's right and surely the dismount operation removed one of the virtual disks and just removed the drive letter of the other one? I mean so it would have been possible to assign a new drive letter to and continue to use it? There have been a few threads about this in this forum over the years. Not very often, but a few now and then.

[v77]

That's right and surely the dismount operation removed one of the virtual disks and just removed the drive letter of the other one?

Yes, the second one is still present in the control panel applet, but its drive letter has disappeared.

[Morten Due Jørgensen]

Hi again, Olof and v77,

 

v77, that is exactly right. Issuing the command caused the disk to appear in the applet WITHOUT a drive letter, yet Windows offered me (correctly) to format the R: drive.

 

Issuing the command again (from an elevated prompt) caused a second disk with drive letter R: to appear in the applet. I now understand from Olof's explanation that drive letter reuse is by design. No problem. The second issue was that when I tried to remove the FIRST disk, the one without the drive letter, it was removed indeed, but the SECOND disk - the one WITH the drive letter in the applet - lost it's drive letter and became inaccessible.

 

Sorry, if I wasn't all clear about everything.

 

I just tried again, this time with another disk already correctly mounted and formattet, and then the command created a second disk WITH a drive letter in the applet, so apparently you have to start with a clean slate to reproduce this. Removed all drives, and all was reproducable again. (BTW, I am running on a Windows 7 N, let me know, if you need more info.)

 

All this is not a problem for me, it is easy enough to avoid the issue, I just thought I'd report it all the same. Wasn't aware about the fixed/removable difference though, I will dig a little into that, to see what fits my purpose best - thanks Oluf.

 

Morten