Jump to content











Photo
- - - - -

Possible bug or incompatibility in ImDisk

imdisk bug

  • Please log in to reply
11 replies to this topic

#1 fzzzt

fzzzt
  • Members
  • 6 posts
  •  
    United States

Posted 19 June 2016 - 12:09 PM

I use ImDisk to create a RAM drive for my %TEMP% folder in Windows. I was working on a NodeJS application which creates temporary files, and the latest version of NodeJS no longer works when attempting to write the files. Apparently they switched to another library which doesn't work with ImDisk, some more information is available here:

 

https://github.com/n...mment-226982491

 

My question is regarding the comment in that discussion:

 

I speculate that the GetFinalPathNameByHandle(VOLUME_NAME_DOS) call fails with ERROR_INVALID_FUNCTION. Libuv maps it to EISDIR for historic (and arguably wrong) reasons.

 
I can't say for sure but it's quite possibly a bug in the ramdisk driver. For example, if it doesn't support CreateFile(FILE_FLAG_BACKUP_SEMANTICS), then the GetFinalPathNameByHandle call is going to fail for directories and empty files.

 

Can anyone confirm if this might be a bug in ImDisk or if it's a compatibility problem? I read the Compatibility section on the ImDisk web site, and tried Arsenal Image Mounter, and that worked. Unfortunately AIM doesn't have any of the features that I use in ImDisk so it isn't really a viable replacement as far as I can tell... I've had other weird problems in the past with other applications as well, which may be due to something similar, which is really disappointing.

 

This is the command I use to create the RAM disk, in case it is something I am doing that causes this (I've tried various alternative commands and nothing solved the problem):

imdisk -a -t file -o awe,rem -s 4096M -S 4096 -m R: -p "/fs:ntfs /v:RAM /A:4096 /q /y"

Edited by fzzzt, 19 June 2016 - 12:09 PM.


#2 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

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

Posted 20 June 2016 - 08:31 AM

Yes, there have been similar reports from other users as well. Applications that rely on things like GetFinalPathNameByHandle and a few other functions are likely to fail on ImDisk virtual disks. These functions need the disk volume to be managed by Volume Mount Manager to find mount points and similar. ImDisk does not interact with Volume Mount Manager at all, so all such operations will fail.

 

I am curious about what particular features you feel are missing in Arsenal Image Mounter? The low-level command line tool is made in a way that should normally make transition from imdisk.exe easy. If you just replace "imdisk" with "aim_ll" in your command line:

imdisk -a -t file -o awe,rem -s 4096M -S 4096 -m R: -p "/fs:ntfs /v:RAM /A:4096 /q /y"

Switch to:

aim_ll -a -t file -o awe,rem -s 4096M -S 4096 -m R: -p "/fs:ntfs /v:RAM /A:4096 /q /y"

Do you get any problems? What features are missing?

 

If you have any problems with Arsenal Image Mounter, feel free to report!



#3 fzzzt

fzzzt
  • Members
  • 6 posts
  •  
    United States

Posted 16 July 2016 - 11:51 AM

The downloadable Arsenal Image Mounter doesn't come with the CLI utilities, I didn't know they existed. After finding them, they do work, the only problem is that it pops up a dialog window when creating the drive that prompts the user to format the drive, even if the auto-format arguments are used. imdisk itself doesn't do this so maybe it's something to do with it appearing as a real volume. It's a minor bug really. Since I create the disk on startup I'll see it every time, just an annoyance.

 

Thanks for tipping me off to aim_ll



#4 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 16 July 2016 - 12:07 PM

The downloadable Arsenal Image Mounter doesn't come with the CLI utilities, I didn't know they existed. After finding them, they do work,

And where did you find those CLI utilities? (I mean, they may be useful to other people if publicly available).

You mean these, right?:

http://reboot.pro/to...unter/?p=195261

https://github.com/A...ne applications

 

@Olof

Inside the aim_ll.zip archive there is a "IMDISK control Panel" imdisk.cpl.

Is this intended?

Or it is a misname and actually it uses the aim_ll.exe, the ctlunit/phdskmnt.sys (or *whatever* driver) ?

 

:duff:

Wonko



#5 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

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

Posted 22 July 2016 - 09:58 PM

@Olof

Inside the aim_ll.zip archive there is a "IMDISK control Panel" imdisk.cpl.

Is this intended?

Or it is a misname and actually it uses the aim_ll.exe, the ctlunit/phdskmnt.sys (or *whatever* driver) ?

 

It is included because aim_exe.exe has a direct dependency on imdisk.cpl. It does not depend on the ImDisk driver so it would be somewhat stupid to ask users to install ImDisk first to be able to run aim_ll.exe. All it uses in imdisk.cpl are some functions for example for opening devices by native name, load drivers, find free drive letters etc. So I thought it would be better to simply include imdisk.cpl in that package.



#6 fzzzt

fzzzt
  • Members
  • 6 posts
  •  
    United States

Posted 23 July 2016 - 01:20 AM

And where did you find those CLI utilities?

 

Sorry, I got them from the GitHub repository (the same one to which you linked).



#7 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 23 July 2016 - 09:53 AM

It is included because aim_exe.exe has a direct dependency on imdisk.cpl. It does not depend on the ImDisk driver so it would be somewhat stupid to ask users to install ImDisk first to be able to run aim_ll.exe. All it uses in imdisk.cpl are some functions for example for opening devices by native name, load drivers, find free drive letters etc. So I thought it would be better to simply include imdisk.cpl in that package.

I see :), though it sounds like a possible source of issues, I mean what if the user has already an (earlier/obsolete/whatever) IMDISK fully installed (and thus it has its Imdisk.cpl already installed) wouldn't there be the possibility of a conflict of some kind? :unsure:

 

@fzzzt

No prob :).

 

:duff:

Wonko



#8 friske

friske

    Frequent Member

  • Advanced user
  • 244 posts
  •  
    Italy

Posted 23 July 2016 - 10:33 AM

I am curious about what particular features you feel are missing in Arsenal Image Mounter?

I not can to use "dynamic memory management" with RamDyn.



#9 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

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

Posted 23 July 2016 - 05:17 PM

I see :), though it sounds like a possible source of issues, I mean what if the user has already an (earlier/obsolete/whatever) IMDISK fully installed (and thus it has its Imdisk.cpl already installed) wouldn't there be the possibility of a conflict of some kind? :unsure:

 

Could be. If the user has an ImDisk version < 2.0.0 (IIRC) installed, that version of imdisk.cpl will not work. aim_ll.exe will complain about missing export functions in imdisk.cpl. Not a huge problem in my opinion. All functions used by aim_ll.exe are "stateless" and do not alter any global states in imdisk.cpl or require anything particular to have happened within imdisk.cpl before the calls.

 

If it turns out to be a practical problem for someone I could of course reconsider this and build a few needed functions into both imdisk.cpl and aim_api.dll, or something like that.

 

I not can to use "dynamic memory management" with RamDyn.

 

That's probably right. My intention here was to compare ImDisk Virtual Disk Driver with Arsenal Image Mounter driver and their related control applications and API libraries. But there could of course be features in for example ImDisk Toolkit, which is a separate application, that cannot be used with Arsenal Image Mounter. But still an interesting question of course. :)



#10 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 23 July 2016 - 05:48 PM

Could be. If the user has an ImDisk version < 2.0.0 (IIRC) installed, that version of imdisk.cpl will not work. aim_ll.exe will complain about missing export functions in imdisk.cpl. Not a huge problem in my opinion. All functions used by aim_ll.exe are "stateless" and do not alter any global states in imdisk.cpl or require anything particular to have happened within imdisk.cpl before the calls.

 

If it turns out to be a practical problem for someone I could of course reconsider this and build a few needed functions into both imdisk.cpl and aim_api.dll, or something like that.

Yep :), I also don't think it may become a "real" problem, out of curiosity, what would happen if the user has a <2.00 (or whatever) IMDISK installed and overwrites the "old" .cpl with the new one?

 

:duff:

Wonko



#11 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

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

Posted 23 July 2016 - 06:10 PM

Yep :), I also don't think it may become a "real" problem, out of curiosity, what would happen if the user has a <2.00 (or whatever) IMDISK installed and overwrites the "old" .cpl with the new one?

 

You mean if someone copies the imdisk.cpl included in aim_ll.zip archive to system32 directory and overwrites the one installed by ImDisk? Nothing in particular I suppose. They get a newer version with some bugs fixed since the version they were using before. If they try to use a feature not available in the older version of ImDisk driver they have installed the driver will return an error message that will be returned to calling application, or shown in a message box if Control Panel applet is used.



#12 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13329 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 24 July 2016 - 09:07 AM

You mean if someone copies the imdisk.cpl included in aim_ll.zip archive to system32 directory and overwrites the one installed by ImDisk? Nothing in particular I suppose. They get a newer version with some bugs fixed since the version they were using before. If they try to use a feature not available in the older version of ImDisk driver they have installed the driver will return an error message that will be returned to calling application, or shown in a message box if Control Panel applet is used.

Yes, that is what I meant, but as long as the imdisk.cpl is "backwards compatible" that won't cause any issue. :thumbsup:

 

 

:duff:

Wonko







Also tagged with one or more of these keywords: imdisk, bug

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users