Jump to content











Photo
* * * * * 1 votes

vMount

vhd

  • Please log in to reply
222 replies to this topic

#201 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2877 posts
  • Location:Nantes - France
  •  
    France

Posted 04 July 2020 - 02:08 PM

@erwan

The command you just posted:

vmount-win64 O:\ %volume% 

 

Makes no sense whatsoever (AND it is seemingly undocumented in the thread).

 

The usage of a command line tool NEEDS to be consistent.

 

All examples till now were:
Command <action> [parameters]

your seems:
Command <drive letter> <confusing separator (duly noticed)> <undefined variable>

 

Maybe you could spend a few lines detailing and explaining it.

 

:duff:

Wonko

 

Well allow me to disagree there :)

 

First of all the 1st post of this thread makes it clear that you can pass several arguments to the assign "verb".

And although it is discussable (i.e is it consistent or not) to make a distinction between x: and x:\, the help output is rather explicit about this.

vmount assign x: \device\harddiskX\partitionY
vmount assign x:\ \\?\Volume{GUID}\
vmount assign x:\mount\ \\?\Volume{GUID}\
vmount assign x: \\ip\smb_share [username] [password]
vmount assign x: ip:/nfs_export [username] [password]

This matter has been discussed/documented a few times in this thread (device path versus volume path and the first one NOT requiring admin rights when the later does).

 

http://reboot.pro/to...521#entry208521 (new feature was announced there : device/volume/nfs/smb)
http://reboot.pro/to...530#entry208530 (device vs volume was reiterated there)
http://reboot.pro/to...761#entry208761 (use of DefineDosDevice was explained there)
http://reboot.pro/to...373#entry211373 (one use case there using assign against a dos device)
http://reboot.pro/to...401#entry211401 (assign device vs volume re iterated there)
 
If a device path is given, vmount will use DefineDosDevice and this does not require admin rights.
If a volume path is given, vmount will use SetVolumeMountPointA and this requires admin rights.
If a smb or nfs path is given, vmount will use WNetAddConnection2 and this does not require admin rights.
 
Hope this will make it clearer.
 
Regards,
Erwan


#202 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 04 July 2020 - 02:35 PM

 

Well allow me to disagree there :)

 

First of all the 1st post of this thread makes it clear that you can pass several arguments to the assign "verb".

 

Sure :), but the point I was trying to make is that using invisible ink to write "assign", or - more generally - <action> or "verb", as you did here:

 

 

 


If you were to use vmount-win64 O:\ %volume% (notice the \ after O:), then vmount would use another set of windows API's (related to volumes) and you would have to provide a volume path.

 in a command is severely prohibited since the 1955 International Convention of programmers ;), as well as using an undefined variable in an example command line, but this latter is only frowned upon.

 

Now that you have cleared that by:

 

vmount-win64 O:\ %volume%

you actually meant:

 

 

vmount-win64 assign O:\ \\?\Volume{GUID}\

 

everything is cool and dandy.  :thumbsup:

 

Still it remains not correct that a same argument (what windows calls a drive letter) within the same command/action/verb has to be expressed in two different ways (BTW both usually correct on command line, i.e. DIR D: or DIR D:\ have the same output) depending on the second argument used.

 

How would you write it in a "canonical" way?

 

vmount assign <drive letter|mountpoint>|<drive letter followed by backslash> <\device\harddiskX\partitionY>|\\?\Volume{GUID}\

As always I may be wrong, but the generic syntax is

vmount assign <target> <source>

 

Where target and source can be:

 

drive letter with-no-following-backslash IF source is if the type \device\harddiskX\partitionY OR \\ip\smb_share [username] [password] OR ip:/nfs_export [username] [password] (please notice how the "ip" in one case needs to be prepended by a double backslashm but there are none in the other)

drive letter with-following-backslash OR mount point (that always ends with a backslash) IF source is of the type \\?\Volume{GUID}\

 

So you have two possible targets, drive letter or mountpoint of which one may end with a backslash or not whist the second must end with backslash and 5 possible sources, of which 3 needs to begin with a double backslash, one needs to have a single one and one needs none.

 

Is it not possiby confusing?

 

Since both these are "correct":

 

vmount assign x: \device\harddiskX\partitionY
vmount assign x:\ \\?\Volume{GUID}\

 

would it be so difficult to make also:

 

vmount assign x:\ \device\harddiskX\partitionY

and
vmount assign x:\ \\device\harddiskX\partitionY

 

 

and of course also:

vmount assign x:\ \\ip\smb_share\device\harddiskX\partitionY
vmount assign x:\ \\ip:/nfs_export [username] [password]

 

acceptable?

 

Simple rule (hypothetical):

target should always end with a backslash (and you remove it in the parser when it is unneeded)
source should always start with a double backslash (and you remove one or both in the parser when it is/they are unneeded)

 

:duff:

Wonko 



#203 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2877 posts
  • Location:Nantes - France
  •  
    France

Posted 04 July 2020 - 04:12 PM

...

Is it not possiby confusing?

 

Since both these are "correct":

 

vmount assign x: \device\harddiskX\partitionY
vmount assign x:\ \\?\Volume{GUID}\

 

would it be so difficult to make also:

 

vmount assign x:\ \device\harddiskX\partitionY

and
vmount assign x:\ \\device\harddiskX\partitionY

 

 

and of course also:

vmount assign x:\ \\ip\smb_share\device\harddiskX\partitionY
vmount assign x:\ \\ip:/nfs_export [username] [password]

 

acceptable?

 

Simple rule (hypothetical):

target should always end with a backslash (and you remove it in the parser when it is unneeded)
source should always start with a double backslash (and you remove one or both in the parser when it is/they are unneeded)

 

:duff:

Wonko 

 

You were right, as always  :D

I reviewed my code and it was pure lazyness...

 

All the below will work (new zip uploaded).

 

vmount assign x:\ \device\harddiskX\partitionY

vmount assign x:\ \\?\Volume{GUID}\

 

vmount assign x: \device\harddiskX\partitionY

vmount assign x: \\?\Volume{GUID}\

 

vmount assign x: \\ip\smb_share\device\harddiskX\partitionY
vmount assign x: \\ip:/nfs_export [username] [password]

vmount assign x:\ \\ip\smb_share\device\harddiskX\partitionY

vmount assign x:\ \\ip:/nfs_export [username] [password]

 

In short you are free to use x: or x:\ (vmount will add or remove a \ whenever needed).

And following your advice, i could (should?) update the help output to always go for a target ending with a backlash.

 

Thus I did not follow you advice for now on any source always starting with \\.

I am not comfy with \\device\harddiskX\partitionY and this especially when vmount devices will output \device\harddiskX\partitionY .

 

And of course this could lead to the syntax I use for the remove verb (x: meaning a dos device and x:\ meaning a volume) ...



#204 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 05 July 2020 - 07:34 AM

Very good. :)

 

erwan.l, on 04 Jul 2020 - 6:12 PM, said:
Thus I did not follow you advice for now on any source always starting with \\.

I am not comfy with \\device\harddiskX\partitionY and this especially when vmount devices will output \device\harddiskX\partitionY .

Of course you are right, the double slash in this case is actually "improper".

I am not too sure to understand this:

 

erwan.l, on 04 Jul 2020 - 6:12 PM, said:
And of course this could lead to the syntax I use for the remove verb (x: meaning a dos device and x:\ meaning a volume) ...

I mean, if I get this right, a "local" device "exists".

This device, let's say for the sake of the example is \device\harddiskX\partitionY but it is also, at the same time, a given \\?\Volume{GUID}\.

Now, there are two ways that technically use two different Windows functions/DLL's/whatever, one of which needs Admin right, whilst the other one doesn't) to assign a drive letter to the device

So, if someone is logged in with Admin credentials, he/she can use indifferently:
vmount assign x:\ \device\harddiskX\partitionY
OR:
vmount assign x:\ \\?\Volume{GUID}\

and (this is what I believe) the output of:

mountvol X: /L
OR
mountvol X:\ /L
;)
will be the same, i.e. the assign command will have worked in its scope, i.e. to assign the drive letter to the device.

Now, when it comes to removing this drive letter, we have the same double possibility (still as Admin):
1) vmount remove x: <- this removes the drive letter from the device, while accessing it (the device) as \device\harddiskX\partitionY
OR:
2) vmount remove x:\ <- this removes the drive letter from the device, while accessing it (the device) as \\?\Volume{GUID}\
the final result should be exactly the same (and the remove command does what the user expects, i.e. to "free" drive letter x: )

So - if the above is correct, a non-admin user could/should be able to issue indifferently:
vmount remove x:
OR:
vmount remove x:\
and then the vmount.exe could be modified to EITHER:
a. check user credentials and if it is Admin use method 1 and if it is non-admin use method 2) automarically
OR:
b. try using method 1 first and if it doesn't work use method 2
no matter if the trailing backslash is there in the drive letter passed to the command as parameter.

I mean, what the user (Admin, or non-Admin) wants to obtain by using the remove verb/command is clear: remove that particular drive letter assignment, does it make a difference the exact way this drive letter is removed?

Or am I missing something? :unsure:

:duff:
Wonko



#205 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2877 posts
  • Location:Nantes - France
  •  
    France

Posted 05 July 2020 - 11:27 AM

...

Now, when it comes to removing this drive letter, we have the same double possibility (still as Admin):
1) vmount remove x: <- this removes the drive letter from the device, while accessing it (the device) as \device\harddiskX\partitionY
OR:
2) vmount remove x:\ <- this removes the drive letter from the device, while accessing it (the device) as \\?\Volume{GUID}\
the final result should be exactly the same (and the remove command does what the user expects, i.e. to "free" drive letter x: )

So - if the above is correct, a non-admin user could/should be able to issue indifferently:
vmount remove x:
OR:
vmount remove x:\
and then the vmount.exe could be modified to EITHER:
a. check user credentials and if it is Admin use method 1 and if it is non-admin use method 2) automarically
OR:
b. try using method 1 first and if it doesn't work use method 2
no matter if the trailing backslash is there in the drive letter passed to the command as parameter.

I mean, what the user (Admin, or non-Admin) wants to obtain by using the remove verb/command is clear: remove that particular drive letter assignment, does it make a difference the exact way this drive letter is removed?

Or am I missing something? :unsure:

:duff:
Wonko

 

Indeed, by the end, all that matters is what the user wants.

My tools are always kind of "advanced user mode" and currently the user needs to know what he is doing.

Thus, this is no excuse to deliver "guess mode" tools :)

 

About devices versus volumes, one thing to add and to keep in mind :

-a volume will always have a matching device

-a device will not always have a matching volume (imdisk being one good example)

 

Removing a device will always work : first because it does not require admin rights, second because it always exist for a drive letter.

Removing a volume will not always work : first because it does require admin rights, second because it does not always exist for a drive letter.

 

So, indeed I could hide this "complexity" to the user by trying one method (volume), then the other (device).

 

But I where I get bothered there could specific scenarios.

One example that comes to my mind : one may want to remove the drive letter but keep the volume.

 

Current issue may be is to stuff both volume and device removal under the same verb (remove) ?

I could either introduce another verb or add an extra argument to that verb.

 

PS : side note and lets not discuss that for now or else we will lose focus but assigning a drive letter to a dummy/incorrect device will create a situation where you can no longer delete that drive letter (until next reboot) - but can you update it with a correct device.

 

/Erwan



#206 Zharif

Zharif

    Frequent Member

  • .script developer
  • 159 posts
  • Location:Germany
  •  
    Germany

Posted 05 July 2020 - 12:35 PM

 

Removing a volume will not always work : first ..., second because it does not always exist for a drive letter.

...

But I where I get bothered there could specific scenarios.

One example that comes to my mind : one may want to remove the drive letter but keep the volume.

 

 

 

erwan.l,

I'm a little bit confused.

 

From my understanding a device may or may not contain partitions.

If a device contain partitions, some of them may or may not have any partition entry.

For those who have an partition entry and are formatted in a windows well known format (e.g. FAT, FAT32, ExtFAT, NTFS) you could either map or unmap that "volume".

These volumes ALWAYS have either a volume path that can be accessed (e.g. Harddisk1Partition1) as well as a VolumeGUID.

You can map a local volume either by assigning a drive letter or by defining it as local network path.

 

You can set a whole device as offline but you cannot programatically remove it (in fact it is really existant and will always be found at next I/O query but marked as offline).

You can remove the mapping of a volume (e.g. drive letter or local network path) programatically but you cannot not remove the volume programatically (in fact, it is still existant as long as you didn't remove the device/set it offline and will be found at next I/O query).

 

So, what do you mean in particular with:

"...second because it does not always exist for a drive letter".

"...one may want to remove the drive letter but keep the volume."

???

 

Thanks Zharif



#207 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2877 posts
  • Location:Nantes - France
  •  
    France

Posted 05 July 2020 - 12:43 PM

erwan.l,

I'm a little bit confused.

 

....

 

So, what do you mean in particular with:

"...second because it does not always exist for a drive letter".

"...one may want to remove the drive letter but keep the volume."

???

 

Thanks Zharif

 

Example below.

 

t1M8sCc.png

 

I have at least two drive letter mapped against a device, not a volume.

 

R: and X: can only be removed using definedosdevice API, not via DeleteVolumeMountPoint.

 

Hence the need to be able to specifify to vmount if you are removing a device or a volume.



#208 Zharif

Zharif

    Frequent Member

  • .script developer
  • 159 posts
  • Location:Germany
  •  
    Germany

Posted 05 July 2020 - 01:19 PM

Ah, I understand what you mean.

I think you mean unmapped, not removed.

However, although no volume entry/name could be retrieved (for drive letter R:), in fact a partition exist.

Per definition, and if this Imdisk partition is also formatted as eg. NTFS, it should be a volume because it can be mapped via a drive letter and therefore must have a partition entry assigned by windows.

The DeleteVolumeMountPoint-API in fact considers it as volume, otherwise this API wouldn't find it.

Only a volume path is missing because Imdisk doesn't communicate with this API.

So output looks like if it is a device only.

 

For drive letter X:

Device Harddisk0\Partition1 always indicates a PARTITION/VOLUME PATH, never a device path.

Have a look into Winobj.exe (Folder: GLOBAL???). You will see that the device symlink path for a dosdevice is something like "Device\Harddiskn\DRn".

Here, I assume it will be "Device\Harddisk0\DR1"

Considering the fact that you can map a drive letter strenghtens this statement.

 

 

This is my understanding.

So, is it right here to say that  "two drive letters are mapped against a device, but not against a volume"?

 

Very confusing,

Zharif



#209 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2877 posts
  • Location:Nantes - France
  •  
    France

Posted 05 July 2020 - 02:59 PM

Ah, I understand what you mean.

I think you mean unmapped, not removed.

However, although no volume entry/name could be retrieved (for drive letter R:), in fact a partition exist.

Per definition, and if this Imdisk partition is also formatted as eg. NTFS, it should be a volume because it can be mapped via a drive letter and therefore must have a partition entry assigned by windows.

The DeleteVolumeMountPoint-API in fact considers it as volume, otherwise this API wouldn't find it.

Only a volume path is missing because Imdisk doesn't communicate with this API.

So output looks like if it is a device only.

 

For drive letter X:

Device Harddisk0\Partition1 always indicates a PARTITION/VOLUME PATH, never a device path.

Have a look into Winobj.exe (Folder: GLOBAL???). You will see that the device symlink path for a dosdevice is something like "Device\Harddiskn\DRn".

Here, I assume it will be "Device\Harddisk0\DR1"

Considering the fact that you can map a drive letter strenghtens this statement.

 

 

This is my understanding.

So, is it right here to say that  "two drive letters are mapped against a device, but not against a volume"?

 

Very confusing,

Zharif

 

You are right, we are indeed talking about removing a drive letter mapped to a dos device and/or mapped to a volume.

 

The difference volume vs device (when using the verb assign) is now hidden thanks to Wonko's feedback.

But not (yet?) when using the remove verb.

 

About ImDisk, actually, not only does it not support the DeleteVolumeMountPoint, I believe it does not support any volume functions since it does not not register as a volume.

 

About partition, you are absolutely right : there has to be always a partition.

To me, a partition is only a "slice" of a disk with a starting offset and a length.

A partition, "normally" becomes a volume at the windows level, but not always (this is related the discussion we are having here).

 

About "So, is it right here to say that  "two drive letters are mapped against a device, but not against a volume?".

Yes but I will update it with "two drive letters are mapped against a device, but forcibly not against a volume?"

 

For now, to remove a drive letter you can use vmount remove x: or vmount remove x:\ (but only if you are admin AND if there is a volume against that drive letter).

 

Regards,

Erwan



#210 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 05 July 2020 - 06:39 PM

@Zharif

It is a mess.

The explanation by Olof about IMDISK was that it connected over (or below, cannot remember) Mount Manager (as opposed to good ol' VDK, the KernSafe Total Mounter and - later - the same Olof's Arsenal thingy)

Unfortunately when we are talking of devices, volumes, partitions, filesystems, "disk extents" (what I call what erwan.l calls "slices") are not entirely "exact" terms as they belong to a gray area and the exact shade of gray depends oin how you look at them.

A couple of links (one serious, one not so much ;) ) for your interest:

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

http://reboot.pro/to...lack-and-white/

 

@erwan.l

As always I may be wrong, but let's go into practice (besides theory).

 

Let us go back to the assign verb, possible cases:
1) user is Admin and wants to mount a volume[1] to a drive letter -> OK, granted

2) user is Admin and wants to mount a device to a drive letter -> OK, granted

3) user is Admin and wants to mount a device that does not ALSO expose a volume (such as an IMDISK device) to a drive letter -> OK, granted, see #2 above

4) user is NOT Admin and wants to mount a volume[1] to a drive letter -> Not possible
5) user is NOT Admin and wants to mount a device to a drive letter -> OK, granted
6) user is NOT Admin and wants to mount a device that does not ALSO expose a volume (such as an IMDISK device) to a drive letter -> OK, granted, see #5 above

 

The 6 cases above are just 4: 1,2,4,6, and in the remove verb we have the same:

 

1) user is Admin and wants to unmount a volume[1] from a drive letter -> OK, granted

2) user is Admin and wants to unmount a device from a drive letter -> OK, granted

3) user is Admin and wants to unmount a device that does not ALSO expose a volume (such as an IMDISK device) from a drive letter -> OK, granted, see #2 above

4) user is NOT Admin and wants to unmount a volume[1] from a drive letter -> Not possible
5) user is NOT Admin and wants to unmount a device from a drive letter -> OK, granted
6) user is NOT Admin and wants to unmount a device that does not ALSO expose a volume (such as an IMDISK device) from a drive letter -> OK, granted, see #5 above

 

If we use your posted image:
t1M8sCc.png

 

The E:\ (please notice the ending backslash ;)) is a mount point to a device (\Device\HarddiskVolume3) that *something else* (the MountManager) already mapped to a volume.

The C:\ is the same.
The R:\ is a mount point to a device (\Device\Imdisk0) that flew over (or below) the MountManager and thus it is NOT mapped to a volume.

The X:\ is a mount point to the SAME device \device\harddisk0\partition1 that - by another name  (\Device1HardDiskVolume1) was already intercepted by the MountManager and assigned a Volume (but NOT a driveletter/PathName).

 

So the X:\ is connected to the \device\harddisk0\partition1, now, can an Admin assign another driveletter (let's say Z:\ for the sake of the example) to the Volume \\?\Volume{e26e7b15-122a-11e7-82bf-806e6f6e6963}? :unsure:

 

Can he/she assign the SAME driveletter X:\ to the Volume? :dubbio:

 

IF this is possible, then there would be the *only* case where there would be (in theory) a difference between removing the drive letter (a SAME drive letter, in all other case the drive letters are different) from the device OR from the volume.

 

Otherwise the "identifier" is a driveletter, and we can use (sometimes I like it) the English passive form, i.e. instead of saying to the program in gentle and exact terms:

please remove this drive letter from the device it is connected to

OR

please remove this drive letter from the volume it is connected to 

we can tell it:

have this drive letter removed (implied, the grumpy: I don't §@ç#ing care how you do it or to what the heck the drive letter is connected to, just get rid of it :ranting2: )

 

 

 

:duff:

Wonko

 

 

 

[1] I believe that a volume (if it exists) MUST be connected (by the Mount Manager) to a device, or, if you prefer, a device can be "only" a device or "both" a device and a volume, or - maybe even better - a device can be called by its (various) names or - if connected by the Mount Manager to a Volume, by its volume name, but volumes without an underlying device do not exist.



#211 Zharif

Zharif

    Frequent Member

  • .script developer
  • 159 posts
  • Location:Germany
  •  
    Germany

Posted 05 July 2020 - 07:40 PM

Wonko,

No offend, I think I'm totally aware of the grayness here.

But thanks anyway for the links, the first one was really interesting.

 

I know (or let's say I fear) that my input distances us from the original intent of erwan.l's thread (sorry erwan, this should be my last post here).

Anyway, let me show you a list of findings I made over the last years by exploring deviceio and volume management functions.

The lists below shows, how devices and volumes can be accessed by deviceio-apis using the createfile api and all other volume management functions I tried so far.

It is based on the QueryDosDevice-Api.

I know there're several naming conventions around, but let me try to split the syntax for a symlink into two pieces.

Let's talk about a "symlink name" and a "symlink path or target":

 

Symlink paths are unique for a specific device/volume and are device type (sometimes medium type) related.
Known types for storage devices here are Disk, CdRom, Floppy.

Path:   "000000[A-Z0-9][A-Z0-9]*"
Name:  DeviceInstanceIDs like these:
            "{USBSTOR|SCSI|IDE|FDC}*#*{Disk|CdRom|Floppy}*"  (hd|cd|fd device related)

Path:   "Harddisk#*\DR#*"
Name:  "PhysicalDrive#*|Disk{?*}*"                      (hd/device related)

Path:   "HarddiskVolume#*
Name:  "StorageID|DrvLetter|GUID|Harddisk#*Partition#*" (hd-volume related)
            "|BootPartition|SystemPartition"

Path:   "CdRom#*"
Name:  "CdRom#*"                                       (cd device related)
    or!    "DrvLetter|GUID"                              (cd volume related)

Path:   "Floppy#*"
Name:  "DrvLetter|GUID"                                 (fd volume related)
            (maybe "Floppy#*" also, but I've never seen this - would be fd device related, see CdRom)

Path:   "True-/VeraCryptVolume[A-Z]|OSFMDisk#*|ImDisk#*"
Name:  "DrvLetter|GUID"                                 (vd volume related)
  Note:   no IOCTLStorGetDevNr values are assigned here

Reason for this division is that a windows API always assigns a device number > = 0 and a partition number of 0 for a device.

Volumes of a specific device always get the device number of the device and a volume number > 0 (talking in API-terms certainly).

 

About virtual disk drivers:

 

Elby
DiskDriver: Virtual Clone Drive
DiskDriverTarget: ElbyCDIO
DiskDriverName: ElbyCDIO
VolumeTarget: usually As PhysicalDrive
VolumeName: na

Kernsafe
DiskDriver: TotalMounter
DiskDriverTarget: iFlyDiskEx\iFlyDiskEx[0-9]
DiskDriverName: Kernsafe_iVolume
VolumeTarget: usually As PhysicalDrive
VolumeName: na

Passmark
DiskDriver: OSFMount
DiskDriverTarget: OSFMDiskCtl
DiskDriverName: OSFMDiskCtl
VolumeTarget: as PhysicalDrive or as OSFMDisk[0-9]*
VolumeName: drvletter only

Olof Lagerkvist
DiskDriver: ImDisk
DiskDriverTarget: ImDiskCtl
DiskDriverName: ImDiskCtl
VolumeTarget: ImDisk[0-9]*
VolumeName: drvletter only

EZB -Systems
DiskDriver: UltraISO
DiskDriverTarget: IsoCdRom
DiskDriverName: IsoCdRom
VolumeTarget: IsoCdRom[0-9]*
VolumeName: drvletter only

IDRIX-/TrueCrypt-Group
DiskDriver: Vera-/TrueCrypt
DiskDriverTarget: Veracrypt/TrueCrypt
DiskDriverName: Veracrypt/TrueCrypt
VolumeTarget: VeraCryptVolume [A-Z]
VolumeName: drvletter and GUID

 

This is just left for discussion.?

 

Zharif
 



#212 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 July 2020 - 09:25 AM

Blast from the past, from the Author that presumably started it all (Christoph H. Hochstaetter) with his mnt/unmount program in 1996:
https://www.sac.sk/d...isk/unmnt10.zip

 

From its README.WRI (yes, at the time Microsoft Write was a thing) on the specific matter:

 

 

UNMOUNT is a utility, that does what you tell it. E.g. If you have Windows NT on drive C: and you type UNMOUNT -bel C:, then drive C: will be immediately gone. Period. You will have to use MNT to redefine C:. If MNT was also on C: you will have to Shutdown by pressing Ctrl-Alt-Del and then select shutdown. So be careful and use UNMOUNT -el C: instead.

;)

 

Now, seriously, re-reading it I noticed it has a (nice :unsure:, useful :dubbio:) mechanism for stacking up multiple definitions, maybe it is something that may be added/implemented in vmount too?

 

 

 

If you define a drive letter, that is already defined, this will neither result in an error nor overwrite the current definition. Instead the old definition will be put on a stack and the new definition will come into effect. When you undefine the current definition, the current definition will be discarded and the last definition will be recent again. MNT without parameters shows you all definitions for a drive in a seperate line. The topmost line for a drive is the recent definition.

 

 

:duff:

Wonko



#213 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2877 posts
  • Location:Nantes - France
  •  
    France

Posted 07 July 2020 - 10:19 AM

About

 

Now, seriously, re-reading it I noticed it has a (nice  :unsure:, useful  :dubbio:) mechanism for stacking up multiple definitions, maybe it is something that may be added/implemented in vmount too?

 

Quote

 

 

 

If you define a drive letter, that is already defined, this will neither result in an error nor overwrite the current definition. Instead the old definition will be put on a stack and the new definition will come into effect. When you undefine the current definition, the current definition will be discarded and the last definition will be recent again. MNT without parameters shows you all definitions for a drive in a seperate line. The topmost line for a drive is the recent definition.

 

 

Yes, this is a default behavior I have indeed witnessed with definedosdevice and I should update vmount to list all existing definitions.

You can update one existing drive letter with a new definition and if you remove the last definition, then the previous one (if exist) will prevail.

I suspect that umnt tool from Christoph H. Hochstaetter is based on definedosdevice API and only on this one.

This multiple definitions we are talking here does not apply about to volumes (setvolumemountpoint).

 

To be kept in mind as well : 

-definedosdevice will "mount" whatever you specify even if the device path is incorrect like \some\incorrect\path

-definedosdevice will NOT "unmount" an incorrect path (but you can update the definition with another one)



#214 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 07 July 2020 - 01:40 PM

I suspect that umnt tool from Christoph H. Hochstaetter is based on definedosdevice API and only on this one.

Sure :) and since in the (18803 bytes!) download it is included the source code, one can make sure.

 

 

default:
if (!ValidDrive(argv[1])) Usage(argv[0]);
DefineDosDevice(DDD_RAW_TARGET_PATH,argv[1],argv[2]);
break;

 

This multiple definitions we are talking here does not apply about to volumes (setvolumemountpoint).

Yep :). A volume is "unique" (hence being identified by a GUID), but a (different) drive letter can be assigned to a dosdevice and to a volume that is connected to the same dosdevice (by same or another name), as explained in the .wri much like a SUBST  :w00t:

Spoiler

 

Point is more like IF it has some practical use. :unsure:

 

:duff:

Wonko



#215 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2877 posts
  • Location:Nantes - France
  •  
    France

Posted 4 weeks ago

In post 105, I introduced the verb convert2raw.

 

Syntax is the below:

vmount convert2raw path_to_vhd_or_vhdx path_to_raw

(vhd can be fixed or dynamic - raw can be a file or a device)

 

Examples:

 

vmount convert2raw c:\test.vhd c:\test.img

vmount convert2raw c:\test.vhd \\.\physicaldrive1

 

I have now added the ability to pipe out.

 

Examples:

vmount-win64 convert2raw e:\test.vhd stdout | lz4-win64.exe -1 stdin -f e:\dump.lz4
vmount-win64 convert2raw e:\test.vhd stdout | 7z a e:\dump.7z -si
vmount-win64 convert2raw e:\test.vhd stdout | bzip2 -z > dump.gz
vmount-win64 convert2raw \\.\physicaldrive2 stdout | 7z a e:\dump.7z -si
 
or over the network
vmount-win64 convert2raw e:\test.vhd stdout | nc.exe my-server-ip 9000
and on my-server
nc -v -l -p 9000 > e:\dump.img
 
/Erwan

  • ReTokener likes this

#216 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 4 weeks ago

 

In post 105, I introduced the verb convert2raw.

Post is #104, OK.

 

 

 

 

Syntax is the below:

vmount convert2raw path_to_vhd_or_vhdx path_to_raw

(vhd can be fixed or dynamic - raw can be a file or a device)

 

It seems to me like syntax is now more like:

vhmount convert2raw <vhd_or_vhdx_source> <img_or_device_destination> [ stdout | <other_command(archver)>]

 

Good :)

Even if it isn't needed (nor useful I believe ) here:

 

or over the network

vmount-win64 convert2raw e:\test.vhd stdout | nc.exe my-server-ip 9000
and on my-server
nc -v -l -p 9000 > e:\dump.img

 

Maybe it is not a good idea to create an "exception syntax" where the <img_or_device_destination> is missing and the "stdout" is shifted to second parameter: :unsure:

 

:duff:

Wonko



#217 ReTokener

ReTokener

    Frequent Member

  • Developer
  • 248 posts

Posted 4 weeks ago

Dear Erwan
thank you for further explanations of your fantastic work.
 

vmount convert2raw path_to_vhd_or_vhdx path_to_raw
(vhd can be fixed or dynamic - raw can be a file or a device)

To test this, I used three virtual hard disk images:

GPT.vhd (with some data on it)
Virtual size: 2000 MB
Physical size:   28 MB

Target1.vhdx (raw) fixed
Virtual size: 2000 MB
Physical size: 2020 MB

Target2.vhdx (raw) dynamic
Virtual size: 2000 MB
Physical size: 4096 KB

Test on Win10x64 1909

 attached Target1.vhdx
 set it offline
 applied command: vmount-win64.exe convert2raw C:\GPT.vhd \\.\physicaldrive1
 Return was:      rawvhd OK
 detached Target1.vhdx

same procedure with Target2.vhdx

Both commands worked perfect for applying a vhd(x) to (virtual) Hard-Disk. :thumbup:

Let me sent you best regards and Thumbs-up (again) for the mighty vMount-tool. :magic:

Sincerely   T.

 

 

 

 



#218 virgus

virgus

    Newbie

  • Members
  • 23 posts
  •  
    Italy

Posted 3 weeks ago

Dearest Erwan,

it has been a while since last time I wrote here and hope all is fine for you and all the friends of this community.

I've still to read the new recent updates about vmount but I've an easy question for you.

 

I'm trying to set up vmount on an XP machine and I'm getting the following output

The disks/volumes/partitions commands I tried are working correctly, while "devices" gives and empty output and "getvirtualdiskinfo" gives "Access violation" error.

>vmount.exe attachvhd test.vhd

An unhandled exception occurred at $00000000:
EAccessViolation: Access violation
  $00000000
  $00407F1F

I already tried all the old versions I stored to check if one of these might work with "attachvhd" command but found none :-(

Are those simple things to fix or is there a chance that a future update of vmount might be compiled to be "XP friendly" (even just for the basic attach/mount/unmount/detach functions) or it's too much hassle to achieve backwards compatibility ?

 

Thanks and have a nice weekend,

V.


Edited by virgus, 3 weeks ago.


#219 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2877 posts
  • Location:Nantes - France
  •  
    France

Posted 3 weeks ago

Dear Erwan
thank you for further explanations of your fantastic work.
 

To test this

 

,...

Both commands worked perfect for applying a vhd(x) to (virtual) Hard-Disk. :thumbup:

Let me sent you best regards and Thumbs-up (again) for the mighty vMount-tool. :magic:

Sincerely   T.

 

 

Many thanks for your nice feedback  :)

vMount has been developped thanks to the feedback of reboot.pro people.

Without the positive and constructive comments I got over here, this tool would only be some cloumsy line of codes buried on my hard drive.

 

Cheers Mate !

 

Erwan


  • ReTokener likes this

#220 erwan.l

erwan.l

    Platinum Member

  • Developer
  • 2877 posts
  • Location:Nantes - France
  •  
    France

Posted 3 weeks ago

Dearest Erwan,

it has been a while since last time I wrote here and hope all is fine for you and all the friends of this community.

I've still to read the new recent updates about vmount but I've an easy question for you.

 

I'm trying to set up vmount on an XP machine and I'm getting the following output

The disks/volumes/partitions commands I tried are working correctly, while "devices" gives and empty output and "getvirtualdiskinfo" gives "Access violation" error.

>vmount.exe attachvhd test.vhd

An unhandled exception occurred at $00000000:
EAccessViolation: Access violation
  $00000000
  $00407F1F

I already tried all the old versions I stored to check if one of these might work with "attachvhd" command but found none :-(

Are those simple things to fix or is there a chance that a future update of vmount might be compiled to be "XP friendly" (even just for the basic attach/mount/unmount/detach functions) or it's too much hassle to achieve backwards compatibility ?

 

Thanks and have a nice weekend,

V.

 

Hi Virgus,

 

About vhd functions, there is unfortunately no way i can make this work on XP as I am using windows native API's which were introduced with Vista.

I should review my code so that it does not end into an exception when these functions are executed on XP.

 

About the devices function, let me review it : it should work on XP as well.

 

Regards,

Erwan



#221 virgus

virgus

    Newbie

  • Members
  • 23 posts
  •  
    Italy

Posted 3 weeks ago

Dear Erwan, many thanks for your prompt answer,

I'll figure out an alternative for attaching and mounting on XP.

I used to do it with some utility of which I don't recall the name, but it shouldn't be too difficult to find.

 

ImDisk didn't show the volumes on disk management at the time I used it, so I guess it was something else...

 

Have a nice day,

Virgus.



#222 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 3 weeks ago

ImDisk didn't show the volumes on disk management at the time I used it, so I guess it was something else...

http://reboot.pro/to...nting-problems/

http://reboot.pro/to...blems/?p=188774

 

:duff:

Wonko


  • virgus likes this

#223 virgus

virgus

    Newbie

  • Members
  • 23 posts
  •  
    Italy

Posted 3 weeks ago

 

http://reboot.pro/to...nting-problems/

http://reboot.pro/to...blems/?p=188774

 

:duff:

Wonko

 

Thanks Wonko !  :worship: 

Very interesting and precious topics ! :punk:







Also tagged with one or more of these keywords: vhd

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users