OSFMount issues and missing features

[bugmenot2]

Hello team!

Great many thanks for the application. I'd like to draw your attention to the following things:

1) OSFMount cannot be used as a temporary storage for the user TEMP/TMP (environment variable) folder for MSI installers. Whenever you try to install anything you get this error: "The system cannot find the device or filed specified".

2) It would be great if OSFMount allowed to add RAM disks on system startup automatically without using command line scripts and Task Scheduler tricks.

3) It would be extremely useful if OSFMount supported dynamic memory allocation and memory freeing. This is usually implemented by intercepting the SSD/SCSI TRIM command.

4) It would be great if OSFMount allocated RAM using a user process, vs. allocating it via a windows driver as part of SYSTEM process memory. This might prove useful to improve system stability and to possibly allow to destroy OSFMount RAM allocation and all disks at once by just killing this process.

// Artem S. Tashkinov

[David (PassMark)]

1) We aren't aware of any issue. Maybe MSI require a physical drive and not a volume. But OSFMount can do this if you pick the right options.

2) I guess we could permanently install a service on the machine and have it auto-run then build a new user interface for it. But a) it is a fair amount of work, that we aren't being paid for, and b) most users probably don't want an additional service running on their machine all the time.

3) It is a fair amount of work, that we aren't being paid for and probably not a huge benefit for most people (are many people really trying to create RAM drives larger than the amount of free RAM on their machines?)

4) Not sure if it can technically be done, it would need some research (which again, we aren't being paid for). We aren't aware of any stability problem, so it is difficult to see how stability would improve. You shouldn't be killing the process in order to unmount a RAM drive.

[bugmenot2]

1) Steps to reproduce: regedit -> go to HKEY_CURRENT_USER\Environment -> Change TEMP and TMP from what they are to e.g. R:\Temp where R: is a disk created by OSFMount. Try to install any application which uses the MSI installer, e.g. Unigine Tropics Demo 1.3.

Here's why it fails: http://reboot.pro/topic/22008-getfin...alid-function/

it appears that calling GetFinalPathNameByHandle on files on a RAM disk fails with ERROR_INVALID_FUNCTION, which seems to be translated from an NTSTATUS of STATUS_INVALID_DEVICE_REQUEST.

So, yeah, it would be great if you fixed this issue.

2) I don't think a service is really needed as you can do that via the driver registry Parameters which you can set in your user application.

3) Let's say I want to keep temporary files on a ram disk and also have the ability to delete them in order to have more ram for my work. Right now I have to create/destroy a ram drive to acheive this which is cumbersome at best and tedious at worst. I'm not talking about having a RAM disk larger than the amount of free physical RAM. I'm talking about peacefully coexisting with existing applications and OS caches. Right now OSFMount preallocates the entire RAM disk in RAM and this memory is no longer available even if this RAM disk is 100% free. I do understand it's a fair amount of work, so it's really up to you.

4) This was a nitpick anyways, so let's dismiss it.

[David (PassMark)]

We'll have a look at the GetFinalPathNameByHandle thing.

We are happy to look at the other items if there was either a huge community demand, or someone was willing to fund the development work.
At current RAM prices buying more RAM is a lot cheaper than developing code to dynamically size the disk.

[David (PassMark)]

We had a look at the at the GetFinalPathNameByHandle thing.
This is normal behaviour, as this function is supported by the Volume Mount Manager and it isn't used in OSFMount for mounting volumes.

The workaround would be to mount using 'Physical Disk Emulation' in OSFMount, which will go through the Volume Mount Manager.