222 replies to this topic

[Tokener]

Dear Erwan

thanks for the fast reply.

 

 

I suspect that \\?\Volume{26503745-1125-11e9-9e6f-0002a4b2c832}\ will actually have a drive letter already assigned to it.

 

You are right.

 

Maybe I oversaw this fact:

 

if your volume already has a drive letter assigned to it, you may not be able to assign a new drive letter

 

Having no Drive-Letter for the Volume lets vMount assign a letter correctly.

 

Thanks a lot and best wishes for 2019

 

Sincerely   T.

 

 

[Wonko the Sane]

Isn't this something that can be implemented in the vmount (at next revision/update)?

I mean checking if the given GUID volume has already a drive letter assigned to it and if this is the case provide an error like:

vmount64_181221.exe assign X:\ \\?\Volume{26503745-1125-11e9-9e6f-0002a4b2c832}\

ERROR: Volume{26503745-1125-11e9-9e6f-0002a4b2c832} is already mounted to drive letter E:

 

Which should be more undestandable than:

vmount64_181221.exe assign X:\ \\?\Volume{26503745-1125-11e9-9e6f-0002a4b2c832}\
X:\ mount failed,87,Falscher Parameter

 

Wonko

[erwan.l]

Isn't this something that can be implemented in the vmount (at next revision/update)?

I mean checking if the given GUID volume has already a drive letter assigned to it and if this is the case provide an error like:

 

...

 

Wonko

 

Absolutely, this is a good idea !

Let me plan this for next release.

 

Cheers,

Erwan

[sebus]

It seems that VHDSet are not created:

 

vmount v0.9 by erwan2212@gmail.com

 

W:\temp>vmount createdynamic .\trial.vhds 127000
CreateVHD not ok:The parameter is incorrect

[erwan.l]

New version out.

 

Many times when I create a VHD with vmount, the first thing I do is to launch another software (Clonedisk in my case) to create the disk layout, create a partition, eventually change the disk signature, etc.

 

Since Vmount and Clonedisk share the same code, it was therefore an easy one to add new commands.

 

New command line below.

 

This new version is now built with lazarus/fpc (no more with delphi7) allowing me to generate the x86 and x64 versions in one go.

 

Edit : "changepartidgpt" relates to a discussion initiated by Sebus about GPT partitions and "partitiond unique guid" here.

vmount v0.9 by erwan2212@gmail.com
vmount createfixed path_to_vhd size(MB)
vmount createdynamic path_to_vhd size(MB)
vmount createchild path_to_child path_to_parent
vmount attach path_to_vhd [NOLETTER]
vmount attach path_to_iso
vmount detach \\.\PhysicalDriveX
vmount detach disk_num
vmount detach path_to_vhd
vmount expand path_to_vhd size(MB)
vmount compact path_to_vhd
vmount resize path_to_vhd
vmount merge path_to_child
vmount disks [filter]
vmount partitions [filter]
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]
vmount remove x:
vmount remove mount_point(e.g x:\ or c:\mount\)
vmount volumes
vmount devices
vmount online disk_num
vmount offline disk_num
vmount ro disk_num
vmount rw disk_num
vmount attributes disk_num
vmount createdisk \\.\PhysicalDriveX MBR:GPT:RAW
vmount createpart \\.\PhysicalDriveX MBR [partnum] [startingoffset_in_bytes] [length_in_bytes] [boot:0:1]
vmount createpart \\.\PhysicalDriveX GPT [partnum] [startingoffset_in_bytes] [length_in_bytes]
vmount deletedisklayout \\.\PhysicalDriveX
vmount changediskid \\.\PhysicalDriveX MBR $11223344
vmount changediskid \\.\PhysicalDriveX GPT {11223344-1122-1122-AABB-112233445566}
vmount changepartidgpt \\.\PhysicalDriveX PARTNUM {11223344-1122-1122-AABB-112233445566}
vmount deletepart \\.\PhysicalDriveX MBR:GPT PARTNUM
vmount setpartnumberonembr \\.\PhysicalDriveX PARTNUM

[erwan.l]

Reworked the outout of disks and partitions.

Warning for ppl batching/interpreting these outputs : it may breaks scripts.

 

Partitions output will also display the disk startingoffset (in bytes) of the partitions

>vmount-win64 disks
0 [01020304]    DISK    WDC WDS120G2G0A-00JH30          114480MB        SATA    NON-REMOVABLE
1 [56B682DC]    DISK    Hitachi HDP725016GLA380         152627MB        SATA    NON-REMOVABLE
2 [4C7CB382]    DISK    Virtual Disk                    512MB           UNKNOWN NON-REMOVABLE

>vmount-win64 partitions
C: [SYSTEME]    NTFS    \device\harddisk0\partition2    114126MB        368050176
E: [DATA]       NTFS    \device\harddisk1\partition1    152625MB        1048576
R: [RAMDRIVE]   NTFS    \Device\ImDisk0                 1024MB          32256

[erwan.l]

1/

Added createfixedraw 

 

2/

All vhd commands renamed.

Previous syntax will still work thus (to avoid breaking scripts out there - and as everytime a verb is replaced by another one).

 

From

createfixed,createdynamic,createchild,attach,detach,expand,compact,resize,merge

To

createfixedvhd,createdynamicvhd,createchildvhd,attachvhd,detachvhd,expandvhd,compactvhd,resizevhd,mergevhd

 

3/

Added backupdisksector & restoredisksector 

 

4/

Add refresh

 

New syntax

vmount v0.9 by erwan2212@gmail.com
vmount createfixedraw path_to_raw size(MB)
vmount createfixedvhd path_to_vhd size(MB)
vmount createdynamicvhd path_to_vhd size(MB)
vmount createchildvhd path_to_child path_to_parent
vmount attachvhd path_to_vhd [NOLETTER]
vmount attachvhd path_to_iso
vmount detachvhd \\.\PhysicalDriveX
vmount detachvhd disk_numX
vmount detachvhd path_to_vhd
vmount expandvhd path_to_vhd size(MB)
vmount compactvhd path_to_vhd
vmount resizevhd path_to_vhd
vmount mergevhd path_to_child
vmount disks [filter]
vmount partitions [filter]
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]
vmount remove x:
vmount remove mount_point(e.g x:\ or c:\mount\)
vmount volumes
vmount devices
vmount online disk_numX
vmount offline disk_numX
vmount refresh disk_numX
vmount ro disk_numX
vmount rw disk_numX
vmount attributes disk_numX
vmount createdisk \\.\PhysicalDriveX [MBR:GPT:RAW]
vmount createpart \\.\PhysicalDriveX [MBR] [part_numY] [startingoffset_in_bytes] [length_in_bytes] [boot:0:1]
vmount createpart \\.\PhysicalDriveX [GPT] [part_numY] [startingoffset_in_bytes] [length_in_bytes]
vmount deletedisklayout \\.\PhysicalDriveX
vmount changediskid \\.\PhysicalDriveX MBR $11223344
vmount changediskid \\.\PhysicalDriveX GPT {11223344-1122-1122-AABB-112233445566}
vmount changepartidgpt \\.\PhysicalDriveX part_numY {11223344-1122-1122-AABB-112233445566}
vmount deletepart \\.\PhysicalDriveX MBR:GPT part_numY
vmount setpartnumberonembr \\.\PhysicalDriveX part_numY
vmount backupdisksector \\.\PhysicalDriveX sector_num filename
vmount restoredisksector \\.\PhysicalDriveX sector_num filename

 

[erwan.l]

For fun and following Steve6375 original idea (see discussion about SWITCH_E2B here), but also to demonstrate latest commands.

 

Side note : if the image file is an actual/existing partition, the PBR hiddensec field should be taken care of.

 

extents-win64.exe can be found here.

REM lets create a virtual disk
vmount-win64 createfixedvhd e:\test.vhd 512
REM lets id our new disk
vmount-win64 disks
REM lets create our disk layout (mbr by default)
vmount-win64 createdisk \\.\physicaldrive2
REM lets create a partition (mbr and the whole disk by default)
vmount-win64 createpart \\.\physicaldrive2
REM lets force the system to acknowledge it
vmount-win64 refresh 2
REM lets id our new drive letter on our new disk
vmount devices
REM lets format it
format f: /fs:ntfs /q /y
REM lets check ou new partition which should be 512MB
vmount-win64 partitions
REM lets create a raw image file of 256MB and actually allocate clusters
vmount-win64 createfixedraw f:\part1.img 256 1
REM lets figure if the file is contiguous, its size in bytes and its disk lba in sectors
REM File size in bytes :268435456 Lba : 481792
extents-win64.exe f:\part1.img 
REM lets backup our mbr to restore it later (sector 0)
REM we could restore this mbr right away to sector X if we wanted to
vmount-win64 backupdisksector \\.\PhysicalDrive2 0 original.mbr
REM lets overwrite original part 1 to now point at our part1.img file
REM offset 246677504 = lba * 512 i.e 481792 * 512
vmount-win64 createpart \\.\PhysicalDrive2 MBR 1 246677504 268435456 1
REM lets force the system to acknowledge it
vmount-win64 refresh 2
REM lets id our new drive letter on our new disk
vmount devices 
REM lets format it
format f: /fs:ntfs /q /y
REM lets check ou new partition which should be 256MB
REM we just mounted a partition pointing to a partition image file
vmount-win64 partitions
REM lets tag this new partition
echo "hello" > f:\hello.txt
REM job done, fun over, lets restore our original mbr (sector 0)
vmount-win64 restoredisksector \\.\PhysicalDrive2 0 original.mbr
REM lets force the system to acknowledge it
vmount-win64 refresh 2
REM lets check ou original partition which should be 512MB
vmount-win64 partitions

 

[erwan.l]

I have modified :

vmount createfixedraw path_to_raw size(MB) 
to
vmount createfixedraw path_to_raw size(MB) [alloc:0:1]

Indeed I learned something interesting based on previous post.

Creating a file simply using CreateFile + SetFilePointerto get to the end + SetEndOfFile + CloseHandle

is not like

Creating a file simply using CreateFile + SetFileInformationByHandle/FileAllocationInfo (to keep it contiguous) + WriteFile + CloseHandle

 

In first scenario, which will be fine in most cases, we create a file of size S but clusters are not allocated (yet).

Again this is fine since clusters will be allocated when you actually use this file (or mount it using ImDisk or else).

 

Second scenario is useful if you decide to write directly to the underlying disk using the file LBA (like in previous post).

Indeed, if you dont allocate clusters to the file, the volume filesystem will never "know" about the data you have written on disk as the clusters are actually not yet allocated (by the filesystem).

 

Probably stating the obvious for some guys over here and possibly talking chinese to others but I thought I would share

 

Note for later : SetFileValidData might be an "elegant" way to create a file with allocated clusters in one go.

[Wonko the Sane]

 

Creating a file simply using CreateFile + SetFilePointerto get to the end + SetEndOfFile + CloseHandle

is not like

Creating a file simply using CreateFile + SetFileInformationByHandle/FileAllocationInfo (to keep it contiguous) + WriteFile + CloseHandle

 

In first scenario, which will be fine in most cases, we create a file of size S but clusters are not allocated (yet).

Again this is fine since clusters will be allocated when you actually use this file (or mount it using ImDisk or else).

 

Second scenario is useful if you decide to write directly to the underlying disk using the file LBA (like in previous post).

Indeed, if you dont allocate clusters to the file, the volume filesystem will never "know" about the data you have written on disk as the clusters are actually not yet allocated (by the filesystem).

 

Probably stating the obvious for some guys over here and possibly talking chinese to others but I thought I would share

 

Note for later : SetFileValidData might be an "elegant" way to create a file with allocated clusters in one go.

Hmmm.

 

I suspect that you did those on NTFS, and that what you are/were creating was a sparse file.

I don't think that on other filesystems it will work  

 

If you are into learning experimenting with sparse files, it is a field for which there are not so many tools/utilities available, see as a reference this seemingly unrelated topic:

http://reboot.pro/to...n-many-ramdisk/

where I posted a number of tools I found around:

http://reboot.pro/to...mdisk/?p=192898

 

Wonko

[erwan.l]

Hmmm.

 

I suspect that you did those on NTFS, and that what you are/were creating was a sparse file.

I don't think that on other filesystems it will work

 

If you are into learning experimenting with sparse files, it is a field for which there are not so many tools/utilities available, see as a reference this seemingly unrelated topic:

http://reboot.pro/to...n-many-ramdisk/

where I posted a number of tools I found around:

http://reboot.pro/to...mdisk/?p=192898

 

Wonko

 

Actually, I was going to touch on that : sparse is yet a slightly different topic.

A sparse file will display a file size but will display 0 bytes as size on disk.

But you will actually see no visible difference between a file created without allocating clusters (may be that wording is wrong - let me reword for now "without writing data thru out the whoel file") and a file created with allocated clusters i.e they will both display the same figure in file size and size on disk.

 

To my knowledge, you will only see the difference between a file with/without allocated clusters if you decide to write data directly to the physical disk at the LBA where the file is positionned : you will end up with different results.

Except for this very specific scenario (writing to the physical disk), it makes no difference at all.

 

My little experiment in previous post clearly highlights this behavior (whether you use the allocated flag or not while creating the raw file).

Without allocating clusters to the file in the first place, the volume filesystem will never know about the datas you may write to the physical disk at the location occupied by that file.

[Wonko the Sane]

I don't know  , hence I posted the dubitative reference to sparse files.

AFAIK/AFAICU, SetFileValidData is a "feature" of a filesystem driver:

http://reboot.pro/to...ation/?p=168040

 

The SetFileValidData should be the programmatic way, equivalent to fsutil setvaliddata, see also:

http://reboot.pro/to...s-on-windows-7/

 

Again, sparse files are (in Windows I mean) NTFS only, so if you try those commands on a FAT16 or FAT32 what happens?

 

Wonko

[erwan.l]

I don't know  , hence I posted the dubitative reference to sparse files.

AFAIK/AFAICU, SetFileValidData is a "feature" of a filesystem driver:

http://reboot.pro/to...ation/?p=168040

 

The SetFileValidData should be the programmatic way, equivalent to fsutil setvaliddata, see also:

http://reboot.pro/to...s-on-windows-7/

 

Again, sparse files are (in Windows I mean) NTFS only, so if you try those commands on a FAT16 or FAT32 what happens?

 

Wonko

 

Actually, the first post in your second link touches on that.

 

My point is about (in a NTFS environement) :

fsutil file createnew e:\100MB.img 100000000
VERSUS

fsutil file createnew e:\100MB.img 100000000

fsutil file setvaliddata e:\100MB.img 100000000

 

In both cases, explorer.exe (file size and size on disk) and extents-win64.exe will report the exact same thing.

Note that sparse files are another scenario since size on disk will report 0.

As long as you stick to the volume filesystem handle (or filename handle), setvaliddata does not make much difference.

Quoting MS KB : "This function is useful in very limited scenarios".

 

However, setvaliddata (or simply writing zero bytes thruout the whole file) makes a big difference (at least on NTFS) if you decide to write directly to the physical disk where the file is located (using the file LBA).

That will ensure that the volume filesystem (the MFT to be accurate) is aware of the datas you have written using a physicaldrive handle.

 

Also to rule any confusion, note that this apply if you file is newly created - not if your file is an existing image partition file for example.

[Wonko the Sane]

My point is about (in a NTFS environement) :

 

Sure , and my point is that it is probably peculiar to the NTFS filesystem ONLY and might well behave differently on other filesystems.

 

If you prefer  , you observed a given behaviour   but probably this behaviour applies only to a subset of the filesystems potentially used in the environment where the tool will be used.

 

Consider it only *like* the good ol' professors joke  :

 

http://reboot.pro/to...inybit/?p=66955

 

 

Wonko

[erwan.l]

Sure , and my point is that it is probably peculiar to the NTFS filesystem ONLY and might well behave differently on other filesystems.

 

If you prefer  , you observed a given behaviour   but probably this behaviour applies only to a subset of the filesystems potentially used in the environment where the tool will be used.

 

Consider it only *like* the good ol' professors joke  :

 

http://reboot.pro/to...inybit/?p=66955

 

 

Wonko

 

Probably related to NTFS only indeed.

I need to conduct the same experiment on FAT32 (for example) but then I need to rework my extents-winxx tool to support other filesystems and all at once i feel terrible busy

 

You could update your original thread with the french saying "une hirondelle ne fait pas le printemps".

[Wonko the Sane]

You could update your original thread with the french saying "une hirondelle ne fait pas le printemps".

Sure  , it should mean that France and Italy have both earlier birds


Wonko

[antonino61]

hHhhHAAAHAHAha, yes, that's why they both catch the worm, and presumably fight it out.

[antonino61]

/quote/

"Probably related to NTFS only indeed.

I need to conduct the same experiment on FAT32 (for example) but then I need to rework my extents-winxx tool to support other filesystems and all at once i feel terrible busy  :)"

/quote/

 

do u mean winxs tool? what tool? it must be good against the \windows\winx "inflation", in the square sense of the word. if u come up to something, pls let me know asap, I will carry out the testing. I can bake so many wims and vhds as to allow for all tryouts u wish.

[Wonko the Sane]

do u mean winxs tool? what tool? it must be good against the \windows\winx "inflation", in the square sense of the word. if u come up to something, pls let me know asap, I will carry out the testing. I can bake so many wims and vhds as to allow for all tryouts u wish.

He means this:
http://reboot.pro/topic/18570-extents/

If you get it, it contains:
extents.exe <- GUI tool
and (in \console\):
extents-win32.exe <- command line for Windows 32
extents-win64.exe <- command line for Windows 64

The latter two can be (provisional names) referred to as "extents-winxx tool".

Hopefully - when erwan.l will have some spare time to work on them to add the *needed* features and finalize them, they will become something *like*:

\console\Win32\extentscli.exe

\console\Win64\extentscli.exe

or *whatever* more distinctive from the GUI tool.


Wonko

[antonino61]

This looks like a major thing that could help us big time.

[Wonko the Sane]

This looks like a major thing that could help us big time.

Well, no.

 

It actually makes no sense whatsoever if not for a very small number of people that actually want to know the extents a file actually occupies on a mass storage device, and BTW we already have tools (namely getfileextents and myfragmenter) that can do (most of) that work, JFYI:

http://reboot.pro/to...h-wow64-wanted/

 

The attempted revamp of the extents project is about creating:

1) a command line version <- which will be used only by a subset of the already small target audience
2) a new tool capable of managing "corner" cases, such as UUID volume addresses, $MFT entry embedded files, etc., i.e. those things that currently available tools miss or manage in a not fully correct way.

 

The whole thing only re-started because Steve6375 posted what is almost a chocolate covered banana[1] (again JFYI), i.e. a "wrong" question in the above linked to thread:

 

https://jdebp.eu/FGA...red-banana.html

 

that issue is already (I believe) solved by the re-compiling by erwan.l, both as win32 and win64 bit, of the original getfilextents, so it has in itself a very low priority or actual usefulness in practice.

 

Wonko

 

[1] which is pretty much unusual for Steve, maybe, like everyone else, he is getting older ...

[antonino61]

Thanks for the usual accuracy of the answer.

as for age, we are all getting older

and things ain't like they used to be.

[erwan.l]

...

that issue is already (I believe) solved by the re-compiling by erwan.l, both as win32 and win64 bit, of the original getfilextents, so it has in itself a very low priority or actual usefulness in practice.

 

...

 

Agreed.

As far "extents" and "mft-parse" are concerned, for now they are merely little experiments, based on inputs from a few guys over here like Wonko & Steve3675 which may or may not lead to new tools / ways of doing - or may be merged in some other of my disk related existing tools.

One (humble) advantage may be about "my" extents compared to other similar tools is that I can easily adapt it / customize to people here in this community.

Extents ideally should be discussed here.

Mft-parse may eventually get its own topic (edit : now has a topic here).

 

Vmount, on the other side, which is what this particular post is about, has, I believe, a wider audience and is more "productionized" i.e usable/used on the field.

 

Edit : As for getting old, well... "old" is only a state of mind

...Says the guy who needs to wake up at night to empty his bladder...

[erwan.l]

new version out, few more command line switches...

 

You can now convert any vhd or vhdx file to a fixed vhd or vhdx file and vice et versa.

Therefore, not only can you convert to/from fixed/dynamic but also to/from vhd/vhdx.

The conversion is entirely done by the ms virtual disk api.

vmount convert2fixed path_to_vhd_or_vhdx path_to_vhd_or_vhdx
vmount convert2dynamic path_to_vhd_or_vhdx path_to_vhd_or_vhdx

[Tokener]

dear erwan

thanks again for extending skills of vmount.

it would certainly be helpful if the internal version number was also changed to identify the different files.
the here downloadable file in the forum is still called version 0.8.

dare you and finally give vmount the deserved 1 before the comma.

 

Sincerely   T.