13 replies to this topic

[t_3]

what just happened to me:

 

D:\BIZ\Qt\4.8.7\bin>imdisk -a -m Y -s 8G -o rem -p "/fs:ntfs /q /y"

Creating device...

Error creating mount point:

Das System kann die angegebene Datei nicht finden.

Warning: The device is created without a mount point.

Created device 16844:  -> Image in memory

Formatting disk...

Der Typ des Dateisystems ist NTFS.

Formatieren mit Schnellformatierung 3815318 MB

Bereitstellung des Volumes aufgehoben. Alle offenen Bezüge auf dieses

Volume sind ungültig.

Struktur des Dateisystems wird erstellt.

Formatieren beendet.

       3,6 TB Speicherplatz insgesamt.

       3,6 TB sind verfügbar.

Done.

 

... so i accidentally missed the _:_ after the drive letter _Y_ (which is not in use), and no mount point could be created. nonetheless formatting was executed, but for whatever reason on my drive _X_ instead - and around 3.6TB of data were gone in around 0.2secs.

 

to me this looks like in-line formatting isn't strictly checking if, what and where it will be finally applied.

 

[Olof Lagerkvist]

This sounds really bad and I really wonder how this could happen. If a virtual disk is mounted without a drive letter mount point and command line options request formatting, it creates a temporary drive letter to complete the format. It even checks specifically that this temporary drive letter gets associated with the newly created ImDisk device before proceeding with the format and I must have tested this several hundred times since I have lots of automated and manual test cases for it. So this is really surprising for me to hear. I will do some checks and see what I can find! Thanks for reporting!

[Olof Lagerkvist]

By the way, what version of Windows are you using here? I would like to test on something as closely similar as possible to yours!

[v77]

@t_3:

 

What version of imdisk are you using?

[Olof Lagerkvist]

I have actually reproduced the problem now. I will have a fix ready as soon as I can!

[t_3]

... well most of it is backed up somewhere, somehow, and it's not critical data; could have been worse.

 

sytem is win 7 enterprise x64;

imdisk is latest available (2.0.2).

the accidentally formatted partition was on a gpt volume.

note: the partition was renamed in _windows explorer_ means not showing a drive letter there (but of course had still one on system level).

 

the output i pasted above is directly from the dos box, so i can only say it really happened.

 

some extra details that may help:

i use imdisk to on-the-fly create and remove a ram disk for an automated qt build system which i'm currently working on. it uses a static unit number to create the disk with the -u switch... which is 16843. the idea was to allow to doubtlessly identify the ram disk the app has previously created (i.e. if something goes wrong during the build and the disk was not removed); what turns out to be not ideal anyway since imdisk seems to increment this number if new disks are created without the -u option (as i know now). anyway

 

the complete output when i did it _by hand_, to create a test disk

D:\BIZ\Qt\4.8.7\bin>imdisk -a -m Y -s 8G -o rem -p "/fs:ntfs /q /y"
Creating device...
Error creating mount point:
Das System kann die angegebene Datei nicht finden.
Warning: The device is created without a mount point.
Created device 16844:  -> Image in memory
Formatting disk...
Der Typ des Dateisystems ist NTFS.
Formatieren mit Schnellformatierung 3815318 MB
Bereitstellung des Volumes aufgehoben. Alle offenen Bezüge auf dieses
Volume sind ungültig.
Struktur des Dateisystems wird erstellt.
Formatieren beendet.
       3,6 TB Speicherplatz insgesamt.
       3,6 TB sind verfügbar.
Done.

D:\BIZ\Qt\4.8.7\bin>imdisk -D -u 0
No such device.

D:\BIZ\Qt\4.8.7\bin>imdisk -l
\Device\ImDisk16844
\Device\ImDisk16843

D:\BIZ\Qt\4.8.7\bin>imdisk -D -u 16844
Flushing file buffers...
Locking volume...
Dismounting filesystem...
Removing device...
Done.

D:\BIZ\Qt\4.8.7\bin>imdisk -D -u 16843
Error opening device: Das Gerät wurde entfernt.

D:\BIZ\Qt\4.8.7\bin>imdisk -l
\Device\ImDisk16843

- slightly panicking i first tried to immediately remove unit 0, since i expected the disk to be created as 0;

- then listed the disks since there apparently was no unit 0

- found out, that the unit number was increased from the last unit number i have used

- removed the new disk with unit nbr. 16844 which worked

- and apparently an orphan disk with the initial unit number remained (as it couldn't be removed and actually wasn't there in the system)

 

i know this all sounds a little like "simply don't use it that way", on the other hand the formatting did happen during one single call only, and shouldn't be related to other things that happened before?

 

 

 

btw one other things: would it be useful to optionally turn off the new drive notification (if possible at all)? i have at least one application - contour shuttle driver service - that always crashes when an imdisk is removed (even with the "rem" switch), what does not happen with usb sticks or even hot swap disks; maybe it's just the way the notification works; on the other hand the shuttle driver seems to be not the best piece of software, so...

Edited by t_3, 04 August 2015 - 04:21 PM.

[t_3]

I have actually reproduced the problem now. I will have a fix ready as soon as I can!

 

... glad to have helped at the expense of around 15 million mft entries

 

anyway: thanks for providing this great tool!

[Olof Lagerkvist]

I guess it should be possible to get most of your data back with any tool that recovers accidentally formatted drives. It was a quick format after all.

 

Anyway, when you use -D switch instead of -d, the driver deallocates memory used by the drive and disallows further access to the device object even if the device is still in use. Then, it cannot always remove the actual device object in the kernel if it is in use so it needs to wait some time until the last reference to it is closed. That's why you see the device number still in use after removal with -D switch in some cases. Usually, the device objects will be possible to remove after some time so you will likely eventually see them disappear. You can of course also reboot to remove them.

 

Again, thanks a lot for reporting this formatting wrong drive issue. It seems it only happened when you mounted without a drive letter, request formatting and you had another drive with drive letter X: in the system. This should be the reason why I have not been able to catch this with my automated tests. I have also not tested if it happened on other versions than Windows 7 x64, it could possibly depend on that as well. Anyway, a new version is available for download now where this has been corrected.

[t_3]

... so explicitly only drive letter X?

like X in eXception

guess i should fill out a lottery ticket today.

 

as said, most is backed up, and recovery to regain the rest is already running.

 

thanks for hinting about -d -D; had -D in place when the build system was not yet stable, so i'm going to now use -d instead.

[v77]

I just have read the code changes, and if I understand the fix, in case where no drive letter was given, the drive letter transmitted to the format command was the character 255. Therefore, the consequences depend on the system: the format command should fail, but it still works, with an undefined behavior.

So, the code of imdisk.exe was indeed not clean, but the final test should have be done by the format command, and this is not the case.
This is format.com that have "translated" ÿ (character 255) into X.

Anyway, I will update ImDisk Toolkit right away.

[Olof Lagerkvist]

That's right. I had missed the call to ImDiskFindFreeDriveLetter function that should have been there. This happened to work anyway in most cases, as long as there was no drive X: already in the system or whatever character 255 could get translated into. Funny thing was that even though I had missed that function call I actually had the code in place that verified that the created temporary drive letter really pointed to the correct device. In this case, like you also say, it did actually point to the correct device so it verified ok but format.com translated the "drive letter" link it into something different.

[Wonko the Sane]

I don't know , I don't think that lots of people may accidentally type ALT+0255 when typing a format command.

 

Wonko

[Olof Lagerkvist]

That's right Wonko. It's not particularly strange that format.com has never before been tested for specific "misuses" like this.

[t_3]

btw, i hadn't won the lottery either, and the disk scan (using ZAR) is still progressing at 21%....