Jump to content











Photo
* * * * * 1 votes

vMount

vhd

  • Please log in to reply
164 replies to this topic

#151 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15062 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
  • 2794 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 ReTokener

ReTokener

    Frequent Member

  • Developer
  • 191 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
  • 15062 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
  • 2794 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
  • 2794 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.


  • ReTokener likes this

#157 ReTokener

ReTokener

    Frequent Member

  • Developer
  • 191 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 ReTokener

ReTokener

    Frequent Member

  • Developer
  • 191 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
  • 2794 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
  • 2794 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 ReTokener

ReTokener

    Frequent Member

  • Developer
  • 191 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
  • 1033 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
  • 2794 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
  • 2794 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:

  • ReTokener likes this

#165 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15062 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







Also tagged with one or more of these keywords: vhd

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users