DavidXanatos fork improvements

[Neustradamus]

Dear @LTRData team,

@DavidXanatos has done several changes here:

• https://github.com/DavidXanatos/ImDisk

It can be merged upstream?

Thanks in advance.

[Olof-Lagerkvist]

I am not actively working on ImDisk other than fixing very serious bugfixes when needed. I have also almost not used it for many years now and I do not have any interest in it really other than to provide as easy as possible ways for users to migrate to Arsenal Image Mounter.

However, I think that David's fork looks like a good continuation of the ImDisk project for users who want to continue using ImDisk. I could probably put a link in the README for this repository to his fork.

[Neustradamus]

@LTRData: Maybe you can move this repository into a new organization?

It will be nice to have a new team for this good historical project!

Badly ImDisk username has been taken...

Can you contact GitHub to try to recover it?

• https://support.github.com/contact

I have seen other forks with changes:

• https://github.com/MjrTom/ImDisk
• https://github.com/mridentity/ImDisk
• https://github.com/toyfer/ImDisk
• https://github.com/thainxo/ImDisk

[Olof-Lagerkvist]

That is of course another alternative.

The main reason I have kept it the way it is here "frozen in time", is mainly that I and some other users occasionally want to use ImDisk the way it works here without Mount Manager integration. For example, when mounting the same images several times or when there are reasons to not leave as many traces of mounted volumes in registry or similar. But ideally, this should have been a "simplified" fork and not the other way around. But I just did not expect ImDisk development to continue when I abandoned it something like 10 years ago, considering much better alternatives with much more modern design are available. Now that v77's ImDisk Toolkit has moved on to using Arsenal Image Mounter as "AIM-Toolkit", I would also expect the interest of ImDisk to reduce a bit.

[Neustradamus]

@LTRData: A lot of people use ImDisk...

There are recent builds here:

• https://sourceforge.net/projects/imdisk-toolkit/files/

On website, there are recent builds:

• https://ltr-data.se/opencode.html

A lot of messages here:

• https://sourceforge.net/p/imdisk-toolkit/discussion/general/

A guy search old versions here:

• https://sourceforge.net/p/imdisk-toolkit/discussion/general/thread/78edcc4d28/

It will be good to have a software continuity...

[Olof-Lagerkvist]

@LTRData: A lot of people use ImDisk...

There are recent builds here:

• https://sourceforge.net/projects/imdisk-toolkit/files/

Regarding ImDisk Toolkit, developer v77 has moved on to develop AIM-Toolkit that uses Arsenal Image Mounter instead to overcome ImDisk limitations and outdated driver design. We have both worked pretty hard to provide as easy migration paths as possible.

On website, there are recent builds:

• https://ltr-data.se/opencode.html

Yes, I occasionally do minor updates to serious bugs when I become aware of them. However, as I also mention on that website, ImDisk is based on very old and outdated driver model and I strongly recommend using alternative solutions instead.

A lot of messages here:

• https://sourceforge.net/p/imdisk-toolkit/discussion/general/

A guy search old versions here:

• https://sourceforge.net/p/imdisk-toolkit/discussion/general/thread/78edcc4d28/

It will be good to have a software continuity...

Yes, I realize it is difficult to convince people to migrate away from it. Particularly on very old Windows versions it could still be useful for some experiments and there are not always any reasonable alternatives available in these cases.

[DavidXanatos]

Well more modern design is relative, there is a certain elegance to only emulating a single volume and not an entire disk drive with a full integration into the storage stack. My use case is to provide a file container based encryption (like VeraCrypt does) but based on DiskCryptor's crypto and header format. Keeping it backed by a user mode process instead of fully driver contained is a double-edged sword on one side its better against side channel attacks, on the other any process with administrative privileges can steal the key unless the process is PPL protected or similar. Then any administrative process can while VeraCrypt Volume is mounted steal all its content anyway, so having only the key better protected is of limited use. Simplifying the fork to cover mostly this use case, remove the awealloc (which I see was removed from this repo already) and remove floppy support and may be some other unneeded things may make it even more elegant.

[Olof-Lagerkvist]

Yes I understand and for some kind of experiments that could be useful. But, considering the lack of integration with PnP stacks etc it is not always possible to make device removal reliable. There is no way to avoid leaking device objects after device removal in case something has the device object referenced somewhere. There is no reliable way to synchronize device object lists such to entirely avoid race conditions where different code paths could remove devices simultaneously etc etc. Many such things that are just automatically solved with a driver that uses the full PnP model for a disk drive instead.