GUI, command line and Disk Management

Beautiful toolkit, will be any systems enthusiast's essential swiss army knife

I was not able to figure out one thing though, despite reading threads about it, since they didn't answer the question I had :

1) It does not seem to create entries in Disk Management. Is that intended behavior?
2) Is the GUI complete, so that one can use it without having to touch the command line? I have no problems messing with the cmd line, but the GUI is good and I am not sure if it's intended to be complete or not... Else I'll get familiar with the cmd syntax.

(Moved this to a new thread)

 

Thanks for your kind words!

1.
ImDisk emulates disk volumes, not complete partitionable disks. Also, there is no integration with Volume Mount Manager in Windows, which means that ImDisk volumes do not show up in Disk Management and are not possible to use with mountvol, diskpart and similar tools from command line.

As an alternative to ImDisk, if you need full disk emulation and full integration with various services in the operating system, you could try Arsenal Image Mounter: Direct Download

This is a different kind of driver that emulates a SCSI adapter where virtual disks are attached and removed.

 
2.
The Control Panel applet included with the driver provides access to most common tasks, but you cannot reach the complete set of features in the ImDisk driver using this GUI. You would need the command line tool for that. You could also install the ImDisk Toolkit, which provides a GUI with a lot more features than the built-in Control Panel applet does.

(The horse itself! Authoritative speedy replies FTW!)

• Oh ok.. I always thought it was easier to simulate at the deepest level, so that Windows will take care of the rest, once it believes it is a real disk.. I have zero experience of any of this, but conceptually I thought that's how it would work : add a virtual adapter, add a virtual device, fix some parameters, and let the OS build on it. Seems that that's how Arsenal works. Cool, will check that out!
• I was referring to the toolkit itself... Does it cover all the big features?

The reason I ask is because all my virtual disks are multi-partitioned, so I was wondering if there is at least a way to select the partition that will get mounted as a volume..

BTW I started reading about ImDisk through my effort on http://reboot.pro/to...-gpt-partition/ ... WinVBlock was suggested, which I will check out, but ImDisk seems mature and complete, so wanted to find out how it would fit in. From what I can understand, it cannot serve the purpose, but hoping that you'll drop by and check it out once to confirm. (Warning : it's a very VERY simple aim)

To emulate a disk volume is a relatively easy project to start with. It gets complicated over time though, because certain new OS features, applications etc need modifications and new feature support to work correctly. On the other hand, to emulate a SCSI adapter is a complicated project to start with. It takes some time and effort to make something that could at all do anything. But it is easy to maintain over time, because Windows takes care of implementing all new needed disk features for each new Windows version.

 

About ImDisk Toolkit: "All the big features" is a somewhat relative definition in this context. But it adds things like integration with DiscUtils library to support various kinds of virtual disk formats, automatic creation of ram disks at system startup and a few other popular features.

Is there a way of accessing raw sectors of a given mounted partition?

Is there a way of accessing raw sectors of a given mounted partition?

Sure, access the \\.\logicaldrive. <- which represents the volume, NOT the "partition".

 

For experiments, try the DSFOK toolkit, check it's readme.txt  (and/or the several posts about it's use):

http://members.ozema...eezip/freeware/

 

The only issue may be with the LAST sector of a NTFS volume (the Boot Mirror) because it lies OUTSIDE the logical volume (but inside the partition), see:

http://reboot.pro/to...ated-with-dsfo/

 

Wonko

So you mean \\.\r will give me raw access to R:?

 

Re: partition volume : Not sure. For example I tried mounting a grub BIOS Boot partition (gdisk EF02) ... Windows asked me if it should format the drive.. I clicked cancel.. the drive remained... if there is no filesystem on it, is it the partition that was mounted? Or ?

\\.\R: (including ":") gives you raw access to the R: volume.

Yes.

 

This is a long time debate about the (botched) naming conventions of things.

 

A disk is the "whole thing" or \\.\PhysicalDrive.

 

What IMDISK mounts is the "volume". (and NOT the "disk")

 

What Windows assigns a "drive" letter to is a "volume" or a \\.\LogicalDrive.

 

In the case of a Primary Partition, the "partition" is the same thing as the "volume" BUT with the exception of a NTFS, because of the single added sector at the end.

 

 

Whenever possible, please, use "disk" or \\.\PhysicalDrive for a "disk" ("whole disk" or device), "partition" for a "partition" and "volume" or \\.\LogicalDrive for a "volume", this avoids common misunderstandings (there are several threads where this is debated, but still some of the terms are used mixing them liberally, including the term "filesystem" on which use there is not a universal consensus), JFYI, start areading around here:

http://reboot.pro/to...oting/?p=122274

 

"Final statement" here:

http://reboot.pro/to...oting/?p=123056

 

Wonko

Frankly, and I think this might hurt, considering your very long "final" post detailing the difference between disk, partition, and volume, you complicated matters a whole lot, mixing up things even more than usual, and also remained extremely tied to the MBR disk partitioning, what with "logical" volumes being those things inside the extended partition....

Naah, it doesn't hurt at all .

 

Everyone is free to have his/her own opinions and create his/her own "mental maps" of how things are, and name them whatever he/she likes , the point is only about trying to find a "common ground" or "agreed upon terminology" to avoid misunderstandings when exchanging ideas/informations.

 

The cited "final statement" is not excessively lengthy, it consist of 10 points:

We can say with a righteous degree of approximation that:

1. a disk contains partitions (up to 4 primary or up to 3 primary+1 Extended, which can contain 1 "logical volume" and up to 127 "sub-partitions", each containing a "logical volume")
2. a primary partition contains a "volume" OR "extent" OR "drive"
3. an extended partition normally contains a "logical volume" or "volume" or "extent" or "drive" (first one)
4. an extended partition MAY contain one or more sub-partitions
5. a sub-partition contains a "logical volume" or "volume" or "extent" or "drive"
6. a filesystem is generally applied to any of "logical volume" or "volume" or "extent" or "drive", we can say that a "logical volume" or "volume" or "extent" or "drive" contains a filesystem
7. a filesystem contains directories, files and sub-directories
8. the terms "logical volume", "volume", "extent", "drive" ALWAYS identify a same physical range of sectors of the disk as defined in a partition table, and thus can be (and are) often used as synonyms. In the case of Primary partitions, also the term partition can be used as a synonym of "volume", "extent", "drive".
9. since a "partition" or "logical volume" or "volume", "extent", "drive" is pretty much useless without a filesystem applied to it, often the term "filesystem" is used - somewhat IMproperly - as a synonym to "partition" (primary only) or "logical volume" or "volume", "extent", "drive".
10. Dynamic disks are NOT Basic disks and they are DIFFERENT

 

The way an Extended partition "contains" either one logical volume or more than one sub-partitions, each containing a logical volume, is actually "complex" and possibly the only good thing about GPT is that all partitions are Primary, thus the equation:

primary partition=logical volume=volume

 

can be simplified to

partition=logical volume=volume

 

and the new definition I adopted later that:

... a volume is the *whatever* gets (or can get) a drive letter assigned in windows ...

 

is simple enough, as I see it.

 

For GPT disk it is IMHO just a matter of adding :

0.Points #1 to #10 were stated with reference to MBR disks, but considered the added points #11 and #12, points #1 to #5 do not apply to GPT disks, while points #6 to #10 apply to both MBR and GPT disks.

...

11. for GPT disk all partitions are primary

12. instead of a 4 entry partition table in the MBR there is a similar address table (without a real limit in number of entries, but usually set to 128 entries)

 

Wonko

I think the best way to distinguish : 

 

Disks are block devices, which can be divided into partitions.

 

OSes mount a partition (physical object)  to produce a volume (logical object), which is always of a certain type, which we call a filesystem.

 

And about the trouble I faced while writing to a partition, I now have a sort of solution : If you want to write/read raw data to/from a partition, make sure its partition type value is something recognizable by Windows. Then Windows will allow assigning a drive letter, after which you can change back the partition type.

If you want to write/read raw data to/from a partition, make sure its type code is something recognizable by Windows. Then Windows will allow assigning a drive letter, after which you can change back the partition type.

 

Good morning, Mr. de La Palice .

 

Though - just in order to put a nice stick right between your otherwise nicely rotating gears' teeth   - this may depend (or recent Windows versions) on some  settings in your Registry...

 

JFYI:

http://reboot.pro/to...nsically-sound/

http://reboot.pro/to...t-combinations/

 

Wonko

Very interesting...

 

But obviously I meant being able to write to a partition given that the disk is otherwise writable... Put another way, other partitions could be writable and yet one not be, because of not having a drive letter. "Offline" disks are not considered.

Sure, but if you read carefully, you can have a disk online alright BUT with no drive letter assigned (automatically) to it, and this may depend on these Registry settings (and on the kind of device).

 

Wonko

Gah I get it! My point was about being able to find an access point that allows raw writing, not about completely barring writes! I mean, I could write using the disk device name and a correct offset ; what I was saying was about a slightly higher level of abstraction!

Sure , but I am (notoriously) a very picky kind of guy and this statement:

 

If you want to write/read raw data to/from a partition, make sure its partition type value is something recognizable by Windows. Then Windows will allow assigning a drive letter, after which you can change back the partition type.

seems to convey the idea  that if a partition type is known to windows then a drive letter is assigned to it (or can be assigned to it) in all cases (which is true for - say - 99.99% of common setups  ) I just pointed you to the 0.01% (maybe) "exception that confirms the rule" .

 

Wonko

I revise my stand on partitions and volumes... We should be able to say the volumes we deal with everyday are partition-backed volumes. So volumes are logical structures which only contain filesystem structures... They can be backed by anything, from partitions, to whole disks (superfloppies), to files, to network addresses...

 

Each of these could potentially be able to be mounted, thus creating a volume with it as the backing store. If you think of it this way, then the question arises : is the BPB, along with its "sectors before" field, a part of the volume, or not?

I revise my stand on partitions and volumes... We should be able to say the volumes we deal with everyday are partition-backed volumes. So volumes are logical structures which only contain filesystem structures... They can be backed by anything, from partitions, to whole disks (superfloppies), to files, to network addresses...

With the exception - possibly, and already brought to your attention - of the strange case of NTFS:
http://reboot.pro/to...ated-with-dsfo/
 

Each of these could potentially be able to be mounted, thus creating a volume with it as the backing store. If you think of it this way, then the question arises : is the BPB, along with its "sectors before" field, a part of the volume, or not?

And again, the essential parts (needed) of a BPB have been discussed ad nauseam, lately on threads to which you took part.

cdob proposed what can be the "least amount" of information needed for a volume  (or floppy/super-floppy) PBR (which is a super-set of the BPB) to be "recognized" and "mounted" (in the case of a FAT formatted volume, here:

http://reboot.pro/to...o-gpt/?p=186307

http://reboot.pro/to...r-wim/?p=186268

 

Experiments with a NTFS one are welcome , remembering that in NTFS the PBR is also the file $Boot and is normally 8192 bytes in size.

 

 

What is actually needed in the PBR is different depending IF the scope is "mounting", "accessing" or "booting", and it additionally varies depending on the involved OS or tool/driver, as in the tests documented starting from here (already provided link):

http://www.msfn.org/...e-6#entry987482

 

A similar issue about something being outside of itself has also been raised in this other companion thread on MSFN, JFYI:

http://www.msfn.org/...ation/?p=972261

 

I bolded and underlined the word "Experiments" in the previous sentence to highlight the obvious :

In theory there is no difference between theory and practice, but in practice there is.

 

 

Wonko