Jump to content











Photo
* * * * * 1 votes

vMount

vhd

  • Please log in to reply
222 replies to this topic

#151 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 16 June 2019 - 05:47 PM

Idea is pretty simple :

-figure out how much you can truncate your backend file (a number above the size of your partition+starting offset)

-truncate your vhd which at this point will lose its vhd footer and therefore become invalid

-add a footer back

.... but possibly needing to be refined for NTFS volumes.

 

There may be issues BOTH with the backup NTFS bootsector (which is default on "partitioned media") and with the "twilight zone" which may. or may not exist), you remember?

 

Here:

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

 

:duff:

Wonko



#152 erwan.l

erwan.l

    Platinum Member

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

Posted 16 June 2019 - 05:55 PM

.... but possibly needing to be refined for NTFS volumes.

 

There may be issues BOTH with the backup NTFS bootsector (which is default on "partitioned media") and with the "twilight zone" which may. or may not exist), you remember?

 

Here:

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

 

:duff:

Wonko

 

Actually not sure here.

 

All i am doing really is truncating a file (the backend file aka the VHD).

As long as you keep enough safety room between your truncated number and your partition length, you should not have to care about the extra/backup sectors.

 

Take the following scenario :

-100 GB VHD file with a 90 GB partition/volume

-shrink your volume down to 50 GB

-you can safely truncate your VHD to lets say 55GB and reappend a footer to it - and get back 45GB (100-55).

 

Now indeed, if you want to get back all possible sectors, which is possible, you really need to take any account any possible "twilight zone".

 

Or am I overlooking something / over simplifying?



#153 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 16 June 2019 - 06:16 PM

 

 

 

@Erwan

Just found getvirtualdiskinfo does not work on Win_7x64.

 

2019-06-16 20:06:22 : OSVersion: WIN_7
2019-06-16 20:06:22 : OSArchitecture: X64
2019-06-16 20:06:22 : File: B:\Temp\vMount.exe
2019-06-16 20:06:22 : FileVersion: v1.0.0.12
2019-06-16 20:06:22 : Command: B:\Temp\vMount.exe getvirtualdiskinfo "E:\TEMP\12_F.vhd"
2019-06-16 20:06:22 : Return: OpenVHD SRC failed 87
 

 

Regards   T.

 

 



#154 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 16 June 2019 - 06:26 PM

I don't know, you are talking of GB (give or take a coupe of them :w00t:), I would expect the whole stuff to become (before or later):

1) automatic/autocalculating

2) interfacing with the OS NTFS resizing features

3) accurate at sector level

 

If you prefer, we can already:

1) manually resize a NTFS partition (on 7 and later)

2) truncate a file just fine with good ol' fsz (part of DSFOK ) 

3) make a vhd footer with the simpler Raw2vhd: http://reboot.pro/to...ges/#entry83781

 

The issues with using the current approach are only about the need of being exact with the resizing (of course provided that the user wants to be accurate) amd with the truncating.

 

:duff:

Wonko



#155 erwan.l

erwan.l

    Platinum Member

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

Posted 16 June 2019 - 07:11 PM

I don't know, you are talking of GB (give or take a coupe of them :w00t:), I would expect the whole stuff to become (before or later):

1) automatic/autocalculating

2) interfacing with the OS NTFS resizing features

3) accurate at sector level

 

If you prefer, we can already:

1) manually resize a NTFS partition (on 7 and later)

2) truncate a file just fine with good ol' fsz (part of DSFOK ) 

3) make a vhd footer with the simpler Raw2vhd: http://reboot.pro/to...ges/#entry83781

 

The issues with using the current approach are only about the need of being exact with the resizing (of course provided that the user wants to be accurate) amd with the truncating.

 

:duff:

Wonko

 

Indeed, today the method I went for is truncate the backing file then make a footer, all within the same tool while being able, still in the same tool, to mount/expand/retrieve informations, etc.

Nothing new here.

 

Next logical step is indeed to calculate the minimun/safe size (similar to what the ms virtual disk api do).

 

I am intending thus to stay away from the filesystem and purely use the partition table (which, at least as far as MBR is concerned, includes the backup NTFS sector i.e sectors field in the partition table is +1 compared to the sectors field in the boot sector).

 

Getting down the sector level is defo a good idea and would be quite easy as feeding a value in size (MBytes, Gbytes, etc) is more or less the same as feeding this value in sectors.

 

Utimately the goal here is to make it seamless to the end user and make it appears as if resizing a fixed vhd was identical to resizing a vhdX (when actually, because of OS limitation, it is not).



#156 erwan.l

erwan.l

    Platinum Member

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

Posted 16 June 2019 - 07:31 PM

@Erwan

Just found getvirtualdiskinfo does not work on Win_7x64.

 

 

Regards   T.

 

Good catch, just re uploaded a new version which now support win7 as well.


  • Tokener likes this

#157 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 16 June 2019 - 09:30 PM

 

 

 

 

Dear Erwan

I am very happy that you are working with enthusiasm and seriousness.

It is a great pleasure for me to contribute to the development of vMount.

 

gratefully   T.

 

 

 



#158 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 30 June 2019 - 06:10 PM

 

 

 

Dear Erwan

after doing some extended tests, I found vMount.exe, although stating to set a disk [Readonly],

2019-06-30 20:12:18 : OSVersion: WIN_7
2019-06-30 20:12:18 : OSArchitecture: X64
2019-06-30 20:12:18 : File: B:\Temp\vMount.exe
2019-06-30 20:12:18 : FileVersion: v1.0.0.12
2019-06-30 20:12:18 : Command: B:\Temp\vMount.exe ro 9
2019-06-30 20:12:18 : Return: IOCTL_DISK_SET_DISK_ATTRIBUTES DISK_READ_ONLY Ok

does not set this attribute correct.

This concerns Win7 and Win10 (x64), to VHD and VHDX and real disk.

 

Trying to attach a vDisk by CloneDisk in readonly mode it is done OK, but attribute detected by vMount.exe is still [Normal].

When I try to switch this disk to Read/write mode

2019-06-30 19:50:57 : OSVersion: WIN_7
2019-06-30 19:50:57 : OSArchitecture: X64
2019-06-30 19:50:57 : File: B:\Temp\vMount.exe
2019-06-30 19:50:57 : FileVersion: v1.0.0.12
2019-06-30 19:50:57 : Command: B:\Temp\vMount.exe rw 9
2019-06-30 19:50:57 : Return: IOCTL_DISK_SET_DISK_ATTRIBUTES DISK_READ_WRITE Ok

vMount.exe returnes OK but the state is still Readonly.

 

The same behavior is detected when DISKPART attaches a VDisk-File in Readonly mode.

(Attibute: Normal / unable to switch, although states: IOCTL_DISK_SET_DISK_ATTRIBUTES DISK_READ_WRITE Ok)

 

(BtW. CloneDisk 2.38 crashes when trying to detach a selected vDisk-Drive.)

 

Interesting: what command does CloneDisk use to attach a vDisk-File in Readonly mode?

 

 

Regards   T.

 

 

 

 

 

 

 

 

 



#159 erwan.l

erwan.l

    Platinum Member

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

Posted 01 July 2019 - 06:53 PM








Dear Erwan
after doing some extended tests, I found vMount.exe, although stating to set a disk [Readonly],
does not set this attribute correct.
This concerns Win7 and Win10 (x64), to VHD and VHDX and real disk.

Trying to attach a vDisk by CloneDisk in readonly mode it is done OK, but attribute detected by vMount.exe is still [Normal].
When I try to switch this disk to Read/write mode
vMount.exe returnes OK but the state is still Readonly.

The same behavior is detected when DISKPART attaches a VDisk-File in Readonly mode.
(Attibute: Normal / unable to switch, although states: IOCTL_DISK_SET_DISK_ATTRIBUTES DISK_READ_WRITE Ok)

(BtW. CloneDisk 2.38 crashes when trying to detach a selected vDisk-Drive.)

Interesting: what command does CloneDisk use to attach a vDisk-File in Readonly mode?


Regards T.


Hi Retokener,

Interesting one.
I am not managing to reproduce this matter on my win8.1 x64.
I need to dig some win7 or win10 vm.

As for attaching in ro mode i am using attachvirtualdisk ms api and tweaking the attach_virtual_disk_flag.

Thus I feel that the readonly on a vdisk is not the same readonly as a physical disk.
Surely the ms management console reports it as readonly but only (as least this my theory) because it detects it as a vdisk and therefore uses another api.
Something which clonedisk/vmount does not do : it always uses the "standard" ms api to detect a disk attributes.

I believe that if you mount a vdisk in "default mode" (i.e not readonly), you can then use vmount to set ro/rw.

But if the vdisk has been attached in readonly mode, you cannot then use vmount to set ro/rw.

Will continue investigating.

Regards,
Erwan



#160 erwan.l

erwan.l

    Platinum Member

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

Posted 01 July 2019 - 08:15 PM

While exploring this readonly flag on virtual disks and before eventually introducing a way to correctly report this in vmount/clonedisk, i have uploaded a minor updated vmount version which includes a new "verb".

 

getstoragedependencyinfo will correctly report if a virtual disk is in readonly mode or not (while the standard MS api will not). 

 

getstoragedependencyinfo eventually also reports some other useful informations.

>vmount-win64 getstoragedependencyinfo 2
DependencyDeviceName:\\.\PHYSICALDRIVE2
Flags:READ_ONLY
DependentVolumeRelativePath:\_images\w7.vhd
HostVolumeName:\\?\Volume{876ebd81-ce10-11e8-8334-94de80c2a41e}
DependentVolumeName:


#161 Tokener

Tokener

    Frequent Member

  • Developer
  • 378 posts

Posted 02 July 2019 - 07:52 AM

 

 

Dear Erwan.I

thank you for your efforts.

 

vmount-win64 getstoragedependencyinfo [n]

this command does not return anything on Win7 and Win10.

not at vDisk nor on real disk.

downloaded version number still is 1.0.0.12

 

 

 

Setting a (vitual) disk state to readonly, I noticed the following:

 

Create a new text-file -> obviously OK
Writing to this file and save changes -> obviously OK
Copy this text-file -> obviously OK

Copy files from another drive to the readonly vDisk -> Up to a certain number OK - then stating readonly

After detaching and re- attaching the vDisk, all created files are gone.

So the windows explorer simulated the creation of files.

 

 

As for attaching in ro mode i am using attachvirtualdisk ms api and tweaking the attach_virtual_disk_flag.

how can vMount do this too?

 

 

Regards   T.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



#162 misty

misty

    Gold Member

  • Developer
  • 1069 posts
  •  
    United Kingdom

Posted 02 July 2019 - 06:19 PM

Reminds me of observations in the Is the DISK really Write Protected? Possible Windows API Bug! topic.
 

Whilst helping Erwan with the development of DiskMgr (by testing - LOTS of testing) we noticed a bug with the Microsoft Disk API - more specifically, when using DeviceIoControl+IOCTL_DISK_SET_DISK_ATTRIBUTES.

Please note that the current release of DiskMgr is not affected by this problem as a workaround was introduced (temporarilly setting any ONLINE disk as OFFLINE before applying the changes).

The following behaviour was observed when changing the Read attribute of a DISK (switching between Read-Only / Read-Write) -

OFFLINE DISK
If the target DISK was marked as OFFLINE, then changing the READ attribute worked without any problems.

ONLINE DISK
If the target DISK was marked as ONLINE, then changing the READ attribute appeared to work. As an example, an ONLINE disk was changed from Read-Write to Read-Only. Following the change, the disk attributes were correctly displayed as Read-Only in the DiskMgr UI and also in DiskPart.

Now here's the interesting part - despite the disk being reported as Read-Only it was possible to save a file to the disk (or more accurately to a mounted volume on the DISK). The disk appeared fully accessible (in regards to creating and editing files) from a file manager (Q-Dir) - it was also possible to save files to the disk from NOTEPAD

And another interesting observation. A file created on the disk marked as Read-Only disappeared following an OFFLINE/ONLINE action! I'm wondering if some kind of file based write filter was at play here.....



#163 erwan.l

erwan.l

    Platinum Member

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

Posted 02 July 2019 - 07:20 PM

Reminds me of observations in the Is the DISK really Write Protected? Possible Windows API Bug! topic.
 

 

You are this forum's memory :) (right after Wonko thus ! ).

I tried your suggestion as it sounded indeed very close but no luck.

 

The virtualdisk readonly flag is really something different and unique to the virtualdisk driver I believe.



#164 erwan.l

erwan.l

    Platinum Member

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

Posted 02 July 2019 - 07:25 PM

 

 

 

Dear Erwan.I

thank you for your efforts.

 

this command does not return anything on Win7 and Win10.

not at vDisk nor on real disk.

downloaded version number still is 1.0.0.12

 

 

 

Setting a (vitual) disk state to readonly, I noticed the following:

 

Create a new text-file -> obviously OK
Writing to this file and save changes -> obviously OK
Copy this text-file -> obviously OK

Copy files from another drive to the readonly vDisk -> Up to a certain number OK - then stating readonly

After detaching and re- attaching the vDisk, all created files are gone.

So the windows explorer simulated the creation of files.

 

 

how can vMount do this too?

 

 

Regards   T.

 

Version 1.0.0.13 out.

 

-NOTE : about getstoragedependencyinfo, note that this is lowercase and vmount is (shame on me) case sensitive.

-NOTE : you can type vmount whatevertypo and vmount will silently run - not ideal and will do something about later.

-FIXED : getstoragedependencyinfo will now return an error in most situations (including if you run it against a non vdisk)

-NEW : attributes will now return the readonly flag if the vdisk was mounted in readonly mode

-NEW : attachvhd will now accept a RO parameter

-NOTE : ro and rw will still report OK even on readonly vdisk (when it should ideally report not ok)

-FIXED : detachvhd should work fine on win7 (and that bug was fixed in clonedisk win32 as well)

 

If you are playing with disk attributes (i.e not attaching your vdisk in RO mode), it is worth reading Misty's post above as you may hit some strange behaviors.

 

Also, for now it is safe to consider that setting RO attributes on a disk is not like attaching a vdisk in RO mode even if the end result may appear the same.

 

Note the '*' indicating this readonly is inherited from the vdisk.

The logic is the following : when checking the disk attributes, i will also check if it is a vdisk in readonly mode and if so will report it.

Writing that I just realise Normal should not be reported then if Read-Only ... oh well, next version will fix this minor issue...

 

>vmount-win32 attributes 2

 

Normal Read-Only*

 

Note the flag=5 (permanent + ro)

You may have thought that the developper could just have reported Read-Only instead of a cryptic Flag 5? Well it is without knowing the perverted mind of a developper :)

>vmount-win32 attachvhd e:\test.vhd RO
OpenVirtualDisk OK
Flag 5
AttachVirtualDisk OK
\\.\PHYSICALDRIVE2

Note that DependentVolumeName will always be empty.

Interesting that vdisk api takes either a devicename or a volumename as input.

Could be handy thus later on to retrieve vdisk details based on a volume/drive letter.

 

>vmount-win32 getstoragedependencyinfo 2

DependencyDeviceName:\\.\PHYSICALDRIVE2
Flags:READ_ONLY
DependentVolumeRelativePath:\test.vhd
HostVolumeName:\\?\Volume{876ebd81-ce10-11e8-8334-94de80c2a41e}
DependentVolumeName:

  • Tokener likes this

#165 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 03 July 2019 - 07:54 AM

IMHO (only to reduce the possible confusion) if I get the thingy right:

DependentVolumeName:

shuld be written as:

DependentDriveLetter:

 

A "volume name" is either the "volume name" (as seen in - say - mountvol, i.e. example \\?\Volume{876ebd81-ce10-11e8-8334-94de80c2a41e}) or a "volume label", at least in common understanding.

More technically the drive letter is actually a particular form of mountpoint, so it could also be rendered (more correctly) as:

Mounted_to:

 

:duff:

Wonko



#166 virgus

virgus

    Newbie

  • Members
  • 26 posts
  •  
    Italy

Posted 10 May 2020 - 02:56 PM

Hello Erwan,

thank you so much for this nice tool! :worship:
The vmount remove option is very useful: up to now the only way I had found was to assign C: letter with diskpart.

I've started testing the many functions you implemented and many of them are working greatly at the first shot.

I wish I had found vmount long time ago!

I have already plenty of questions and I read all this thread briefly to better understand all the options of each command, but I already found something worth to ask you.

 

I'm trying to re-write a batch script to allow me to detach a vhd either via its path, or its disc number (which is trivial with vmount) but also via the mounted volume letter. I couldn't find a tool that does this natively unfortunately so I created my own script and added it to the registry HKEY_CLASSES_ROOT\Drive\shell\VhdDetach and finally I can avoid wasting the time to find any vhd file to be able to detach it.

In the first version I made, before knowing of vmount, used "vol" "mbrwiz3" and "diskpart". Too cumbersome even if it's working correctly.

I'm trying to simplify things by using only vmount itself but I'm afraid I'm missing something or doing something wrong.

Here the simple algorithm I thought about in principle (the argument given to the script: VhdPath or DiskNumber or VolLetter):

  1.  - If arg extension is "vhd(x)" check if file exist and launch vmount
  2.  - If arg is a DiskNumber check if the Disk is a "Virtual_Disk" and launch vmount
  3.  - If arg is a VolLetter check if Volume is a "Virtual_Disk", get the DiskNumber and launch vmount

The first two options are pretty easy to achieve but the third one seems cumbersome. Here what I did so far:

::GET DRIVE NUMBER AND VOL LABEL FROM LETTER (OR EVENTUALLY GET LETTER AND DRIVE FROM VOL LABEL)
for /f "tokens=1-5 delims=    " %%1 in ('vmount partitions ^| find "%DLTR%"') do SET VNME=%%2& SET DRIVE=%%4
::REMOVE SQUARE BRACKETS
SET VNME=%VNME:[=%
SET VNME=%VNME:]=%
::EXTRACT DRIVE NUMBER FROM STRING
SET DRIVE=%DRIVE:\device\harddisk=%
for /f "tokens=1 delims=\" %%1 in ('echo %DRIVE%') do SET DRIVE=%%1

I tried to use filters but if I launch vmount partitions C: or vmount partitions "C:" I get no output at all and the find command is unreliable for vmount disks command  EDIT: I just read that the filters are only for the Device column :frusty:

::CHECK IF DISK IS VIRTUAL AND IF IT'S NOT EXITS
for /f "tokens=1,2,3 delims=    " %%1 in ('vmount disks ^| find "%DRIVE%"') do SET DSKNR=%%1& SET PID=%%3
IF ["%PID%"] NEQ ["Virtual_Disk"] EXIT

This seems to work but it's risky even if I add a tab to the find argument. I often use to grep or find strings adding leading and trailing spaces to avoid catching useless rows from a command, but unfortunately here we have no leading tab (or space) to add. Please have a look at my current output (I reduced its rows to simplify):
 

DiskNr    SN    ProductId    Size    Type    Removable
0    [E39479FC]    001-1RG174    1907729MB    SATA    NON-REMOVABLE
2    [69BB67D8]    mSATAM1_064    61057MB    SATA    NON-REMOVABLE
4    [0F679E55]    Virtual_Disk    51200MB    UNKNOWN    NON-REMOVABLE
7    [D625F04F]    RAMDISK    21798MB    UNKNOWN    NON-REMOVABLE
9    [C56FF557]    Virtual_Disk    61057MB    UNKNOWN    NON-REMOVABLE
10    [A0C4A262]    Virtual_Disk    61057MB    UNKNOWN    NON-REMOVABLE

If I use 9 or 10 for %DRIVE%, I get in both cases the correct output, while if I use 4+tab I have three possible results and I would need to parse every single row. This could be simplified by adding a tab before each row. But another great improvement would be to add a column with the disk number in the partitions' output. :thumbsup:

Is there a simpler way to check from a volume letter or a label if the volume is a VHD? Am I making simple things too complex maybe ?

 

--------------------------

Besides this first use, I need also to get the path to the mounted vhd files. I use bginfo to write on screen at boot which is the file I booted from (as I use a common vhd base system for many PCs and then boot from several different diff vhds, depending on each computer or use).

For this purpose I use diskpart but it's not clean and a bit too complex in my opinion and I would love to re-write my script using only vmount.

The simplest algorithm I can imagine could be (argument given to the script: VolLetter or MontPoint) the following:

  1.  - vmount partitions to get the #Disk from the Volume Letter (or eventually mount point)
  2.  - vmount getstoragedependencyinfo to get DependentVolumeRelativePath and HostVolumeName
  3.  - Assemble the previous results accordingly

With diskpart it's quite the same for the vhd's you boot from, but for all the others you get directly the complete vhd path. I don't know why this difference :huh: , there must be a reason that only Wonko, Steve, Wimb and other experts like you might figure out... ;)
As you can see the leading spaces can greatly help reducing the batch file complexity as find "Disk" might catch both "Disk" and "VDisk" " Disk " is different than " VDisk "

C:\Users\Admin>echo list vdisk | diskpart
DISKPART>
  VDisk ###  Disk ###  State                 Type       File
  ---------  --------  --------------------  ---------  ----
  VDisk 0    Disk 10   Attached not open     Expandable  R:\W7U64_2nd_Drivers.vhd
  VDisk 1    Disk 9    Attached not open     Expandable  R:\W7U64_1st_Clean.vhd
  VDisk 2    Disk 4    Attached not open     Fixed       \Device\HarddiskVolume1\NuOS_diff.vhd

Is there a way to get from vmount getstoragedependencyinfo the "DependentVolumeRelativePath:" without passing through vmount volumes command?

vmount volumes | find "HostVolumeName's UUID"

That's all for now.

Again thank you for all the great work you've done so far and for all the improvements to come! 

 

Virgus.

 

PS If you ever come to Paris please drop me a line, I would pleased to offer you a beer or lunch/dinner somewhere! :music_guitar:

PPS I tried to add as many emoticons I could to honor Wonko's  best traditions :rofle:


Edited by virgus, 10 May 2020 - 02:57 PM.


#167 virgus

virgus

    Newbie

  • Members
  • 26 posts
  •  
    Italy

Posted 10 May 2020 - 04:03 PM

Sorry to write another comment but editing my previous one seems forbidden. Can any of the experts please explain me the reason?

 

Anyway I just wanted to ask a question to my last issue: in case the need would be to get the path of a vhd mounted to a path, the only source of information seems to be "vmount volumes" from which we can get Volume# and GUID.

VolumeGuid    Drive    VolName    FS    Size
8    \\?\Volume{7e49f09c-91e3-11ea-9095-b8763fda95ca}\    C:\Test\    [NuVhdOS]    NTFS    61054MB    

I've always wanted to ask if is there a way to get the disk# from the volume# or GUID ?

How could we get the VHD file path in this case ?


Edited by virgus, 10 May 2020 - 04:04 PM.


#168 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 10 May 2020 - 04:03 PM

If I get it right, you want essentially a method to "reconcile" Drive letter, UUID/Vol, and \HarddiskVolumen .

 

Have a look (shameless plug) at ddlist and ddlistw:

http://reboot.pro/to...st-and-ddlistw/

http://reboot.pro/to...listw/?p=173100

 

:duff:

Wonko



#169 erwan.l

erwan.l

    Platinum Member

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

Posted 10 May 2020 - 04:05 PM

Hello Erwan,

thank you so much for this nice tool! :worship:
....

 

Hi Virgus,

 

Thanks for this nice post !

It is a long one so give me some time to process it :)

 

One option you did not explore (maybe?) is the set sep=csv and set skip=1 (command line, dos variable).

This will alter the output of disks, partitions, etc.

May be that can be an extra help for you when parsing...

Search this thread in page 5 for some more details.

 

Example below.

DiskNr;SN;ProductId;Size;Type;Removable
0;[01020304];WDC_WDS120G2G0A-00JH30;114480MB;SATA;NON-REMOVABLE
1;[56B682DC];Hitachi_HDP725016GLA380;152627MB;SATA;NON-REMOVABLE

I'll be back once I have go thru your post.

 

Cheers,

Erwan



#170 erwan.l

erwan.l

    Platinum Member

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

Posted 10 May 2020 - 04:08 PM

Sorry to write another comment but editing my previous one seems forbidden. Can any of the experts please explain me the reason?

 

Anyway I just wanted to ask a question to my last issue: in case the need would be to get the path of a vhd mounted to a path, the only source of information seems to be "vmount volumes" from which we can get Volume# and GUID.

VolumeGuid    Drive    VolName    FS    Size
8    \\?\Volume{7e49f09c-91e3-11ea-9095-b8763fda95ca}\    C:\Test\    [NuVhdOS]    NTFS    61054MB    

I've always wanted to ask if is there a way to get the disk# from the volume# or GUID ?

How could we get the VHD file path in this case ?

 

have you tried the below?

 

vmount-win64.ex getstoragedependencyinfo 2
DependencyDeviceName:\\.\PHYSICALDRIVE2
DependentVolumeRelativePath:\Users\erwan\Documents\-= SOURCES =-\delphi\system\clone_disk\test.vhd
HostVolumeName:\\?\Volume{e26e7b16-122a-11e7-82bf-806e6f6e6963}
DependentVolumeName:


#171 virgus

virgus

    Newbie

  • Members
  • 26 posts
  •  
    Italy

Posted 10 May 2020 - 08:39 PM

Wonko, Erwan many thanks to both of you for your fast answers!

 

If I get it right, you want essentially a method to "reconcile" Drive letter, UUID/Vol, and \HarddiskVolumen .

 

Have a look (shameless plug) at ddlist and ddlistw:

http://reboot.pro/to...st-and-ddlistw/

http://reboot.pro/to...listw/?p=173100

Yes, it would be great to have a single output without the need to collect and assemble informations around

I just tried ddlist and got the following output:

a: 4,1 FIX \Volume{679fc0bf-8fb6-11ea-b199-b8763fda95ca} \HarddiskVolume4
c: 3,1 FIX \Volume{e68e91c2-3054-11e9-8371-806e6f6e6963} \HarddiskVolume3
d: 2,1 FIX \Volume{679fc087-8fb6-11ea-b199-806e6f6e6963} \HarddiskVolume2
p: 0,1 FIX \Volume{c48caf86-90a4-11ea-a69b-806e6f6e6963} \HarddiskVolume1
r: 7,1 FIX \Volume{53167a6c-9298-11ea-91a0-b8763fda95ca} \HarddiskVolume7
s: 6,1 FIX \Volume{679fc0d1-8fb6-11ea-b199-b8763fda95ca} \HarddiskVolume6
Vo 8,1 FIX \Volume{7e49f09c-91e3-11ea-9095-b8763fda95ca} \HarddiskVolume8
z: 5,1 FIX \Volume{e68e91e2-3054-11e9-8371-806e6f6e6963} \HarddiskVolume5

The good part is that the disk information is there. And Disk 8 which is tagged as Vo is a mount point from a VHD file.

But Disk 3 is also a VHD from which I booted and there's no evidence of this.

 

My wish is to get everything done with a single tool.

 

--------------------

 

Getting back to vMount. Thanks Erwan, please don't be in a hurry and take all the time you need:

One option you did not explore (maybe?) is the set sep=csv and set skip=1 (command line, dos variable).

Thanks I missed both options and just scripted four batches for all the cases. Results are here: https://file.io/1Fif3BEu.

 

The problem with vmount disks is still there, no matter the option you chose:

1    [E39479FC]    001-1RG173    1907729MB    SATA    NON-REMOVABLE
2    [5E96978E]    SSD_860_EVO_mSAT    953869MB    SATA    NON-REMOVABLE
3    [0F679E55]    Virtual_Disk    51200MB    UNKNOWN    NON-REMOVABLE

1;[E39479FC];001-1RG173;1907729MB;SATA;NON-REMOVABLE
2;[5E96978E];SSD_860_EVO_mSAT;953869MB;SATA;NON-REMOVABLE
3;[0F679E55];Virtual_Disk;51200MB;UNKNOWN;NON-REMOVABLE

Since the filter only works on the third column, if you parse (with find or grub) the output for the disk #3 (either with "3;" or with "3tab") and one of your productIDs ends with a "3" you won't get a unique result. The leading space or tab or whatever would allow to extend the find or the grep parameters to get an unique result with ";3;" or "tab3tab". One alternative might be to have the Disk Signature as the first column. The other alternative might be to extend the filter option to work also on the first column: if the filter is a number then filter the disk col, otherwise filter the product ID.

 

have you tried the below?

 

vmount-win64.ex getstoragedependencyinfo 2
DependencyDeviceName:\\.\PHYSICALDRIVE2
DependentVolumeRelativePath:\Users\erwan\Documents\-= SOURCES =-\delphi\system\clone_disk\test.vhd
HostVolumeName:\\?\Volume{e26e7b16-122a-11e7-82bf-806e6f6e6963}
DependentVolumeName:

Yes thanks I tried already but did not find a way to get any information if the source is a vhd mount point path.

Imagine that I want to get the file path of a vhd which is mounted to C:\Test (like in my example attached);
I can parse the vMount volumes output and get:

VolumeGuid;Drive;VolName;FS;Size
7;\\?\Volume{7e49f09c-91e3-11ea-9095-b8763fda95ca}\;C:\Test\;[NuVhdOS];NTFS;61054MB;

Here there's no information about the disk detected via vMount disks:

DiskNr;SN;ProductId;Size;Type;Removable
8;[C56FF557];Virtual_Disk;61057MB;UNKNOWN;NON-REMOVABLE

The only common information is the disk size but there's the gap between the whole vhd size and the partition which makes the comparison hard to achieve. There might be an extra info to be able to link the two tables. Possibly taking into account the problem of the filters I mentioned at first.

 

If the extra info would be the Disk# then getstoragedependencyinfo would work at the second vmount call with no extra steps.

 

Another possible alternative would be to extend getstoragedependencyinfo to accept the Guid as parameter ?

-------------

Last but not least: I used to script ImDisk to mount a vhd to a mountpoint but I didn't find a way to do the same with vMount. It seems to me that first I have to attach a vhd and then I can change the mount point to a specific folder. Is that on purpose ? If not, would you please add to the vMount wish list the option to allow attaching and mounting to a mount point ? A kind of extra option like:

vmount attachvhd path_to_vhd [MountPoint_Path] [RO] [cred:username:password]

Of course this is not urgent at all as I might continue using ImDisk for this purpose, but in my DetachVHD script I'd love to be able to detach with "disk","volume letter","vhd path" and also "mountpoint_path".

Ahhh, before I forget this is quite important: I would greatly recommend a sort of "security" to avoid detaching the OS volume. While playing with vmount I tried to remove C:\Test and I got BSOD as I removed the boot vhd from C:\ !!! I put an extra IF in my script but maybe this is a case to avoid for everyone.


Edited by virgus, 10 May 2020 - 08:43 PM.


#172 maro

maro

    Newbie

  • Members
  • 13 posts
  •  
    New Zealand

Posted 10 May 2020 - 10:33 PM

@virgus: Regarding your desire to "properly" match a particular DiskNr I wonder whether you have considered the use of 'findstr' (instead of 'find').
 
I'd imaging that using the '/b' option like   findstr /b "3;"   should help to address your concern. I'm personally a "heavy" user of regular expressions (mostly with 'grep' and 'sed'), so I'd probably use   findstr /r "^3;"    myself (where '^' works as an "anchor" to signify the beginning of a line).



#173 Wonko the Sane

Wonko the Sane

    The Finder

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

Posted 11 May 2020 - 08:55 AM

@Virgus

The link to ddlist/ddlistW was only to give you (hopefully) some inspiration about your batch, those do not take into account any of the Vmount possible outputs.

 

I am not sure (actually I am pretty sure I do not) understand you :dubbio::

 

 

The problem with vmount disks is still there, no matter the option you chose:







1    [E39479FC]    001-1RG173    1907729MB    SATA    NON-REMOVABLE
2    [5E96978E]    SSD_860_EVO_mSAT    953869MB    SATA    NON-REMOVABLE
3    [0F679E55]    Virtual_Disk    51200MB    UNKNOWN    NON-REMOVABLE

1;[E39479FC];001-1RG173;1907729MB;SATA;NON-REMOVABLE
2;[5E96978E];SSD_860_EVO_mSAT;953869MB;SATA;NON-REMOVABLE
3;[0F679E55];Virtual_Disk;51200MB;UNKNOWN;NON-REMOVABLE

Since the filter only works on the third column, if you parse (with find or grub) the output for the disk #3 (either with "3;" or with "3tab") and one of your productIDs ends with a "3" you won't get a unique result. The leading space or tab or whatever would allow to extend the find or the grep parameters to get an unique result with ";3;" or "tab3tab". One alternative might be to have the Disk Signature as the first column. The other alternative might be to extend the filter option to work also on the first column: if the filter is a number then filter the disk col, otherwise filter the product ID.

 

 

If you want to find the *device* #3 in the above, you can look for "3;[" just fine.

Or if you want to find virtual disks without knowing the number it is also easy.

 

I mean:





@ECHO OFF
::vmountfake.cmd

ECHO 1;[E39479FC];001-1RG173;1907729MB;SATA;NON-REMOVABLE
ECHO 2;[5E96978E];SSD_860_EVO_mSAT;953869MB;SATA;NON-REMOVABLE
ECHO 3;[0F679E55];Virtual_Disk;51200MB;UNKNOWN;NON-REMOVABLE





@ECHO OFF
::vmountparse.cmd

FOR /F "tokens=*" %%A IN ('vmountfake.cmd') DO CALL :do_parse %%A
GOTO :EOF

:do_parse
FOR /F "tokens=*" %%B IN ('ECHO %1§%2^|FIND "3§["') DO ECHO This is device #3 and it is a %3: %1 %2 %3 %4

ECHO.

FOR /F "tokens=*" %%B IN ('ECHO %1§%2§%3§%4^|FIND "Virtual_Disk"') DO ECHO Device #%1 is a %3 : %1 %2 %3 %4

:duff:

Wonko



#174 virgus

virgus

    Newbie

  • Members
  • 26 posts
  •  
    Italy

Posted 11 May 2020 - 02:55 PM

Concerning "vmount getstoragedependencyinfo" which I tried to use before Wonko's and Maro's corrections:

I have my boot vhd which is disk 4 and I have others vhds attached.
If I use vmount disk I can see:

DiskNr    SN    ProductId    Size    Type    Removable
4    [11111111]    Virtual_Disk    51200MB    UNKNOWN    NON-REMOVABLE
9    [AE455453]    Virtual_Disk    50000MB    UNKNOWN    NON-REMOVABLE

while getstoragedependencyinfo misses the case when the vhd is a boot disk.

C:\Users\Admin>vmount getstoragedependencyinfo 4
not a virtual disk!

C:\Users\Admin>vmount getstoragedependencyinfo 9
DependencyDeviceName:\\.\PhysicalDrive9
DependentVolumeRelativePath:\STW7.vhd
HostVolumeName:\\?\Volume{bb94dc96-9371-11ea-8d5c-b8763fda95ca}
DependentVolumeName:

Uhm, it could be a permission issue (boot volume versus non boot volume).

I need to try that in a virtual machine...

To start with I could provide an error number along with the generic "not a virtual disk"...


Edited by erwan.l, 11 May 2020 - 08:25 PM.


#175 virgus

virgus

    Newbie

  • Members
  • 26 posts
  •  
    Italy

Posted 11 May 2020 - 05:51 PM

Just a short note about my previous comment:

with usebackq and by passing to findstr (which accepts arguments without quotes) I found the batch solution to get the volume number from the disk number via diskpart:

@echo off
SETLOCAL EnableExtensions enabledelayedexpansion

SET DSK=1
for /F "usebackq tokens=2" %%a in (`"(echo select disk %DSK% ^& echo detail disk) | diskpart | findstr Partition"`) do (set VOLN=%%a)
echo VOLUME NUMBER FOR DISK %DSK% IS: %VOLN%

Sometimes taking a break is really useful ^_^

 

Cheers,

V.

 







Also tagged with one or more of these keywords: vhd

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users