321 replies to this topic

[sfinktah]

Actually, Hyper-V can easily and at once expend a dynamic VDH Disk to a new max size. Its probably in VHD API. Hence, the GUI should allow a user to expend the VHD disk by dragging the handle.

It can be done. There's about 5 pixels of room to the right, so if you drag right and hold, it could just keep getting bigger (that is, the other partitions would seem to be getting smaller).

Its probably in VHD API.

I'm not using the VHD API If I used the VHD API, I'd be limited to the same features as the official Microsoft tools.

I only use the VHD API to mount a VHD. I used DeviceIoControl to implement the cluster view that is the precursor to a defragmentation, and have experimented a little reading the on-disk location(s) of individual files. These two steps are required before you can move the file to a new location. (You have to know where the free space is, and where all the bits of your file are.)

I'm not planning to get heavily into defragmentation, I just wanted to learn enough to see if I could move those pesky files or not.

P.S. The "trim" operation also works on Fixed VHDs. Although the word "works" maybe a mis-use of the term. It doesn't actually make a Fixed VHD file any shorter, it just alters it's footer to claim that it's shorter. So now you can have a 40 MB virtual disk with an 800 MB backing file. Maybe Wonko can hide his porn in there or something.

P.P.S. "vmToolkit" don't use the VHD API either, not in their VMDK converter, or their VHD resizer. They have their own DLLs for both formats.

P.P.P.S. We really need a wiki. I want to link or display topical advice at all points in VHDD, especially when it comes to things it can't do. Even the simplest things like "A list of all VHD manipulation and mounting tools" doesn't exist - and if does, it's likely to be out of date before long.

[sfinktah]

[cdob]

So, once you mount a Win7.vhd to an empty VHD folder, DISM command may look like this?

DISM.exe /image:"c:VHD" /Add-Driver /ForceUnsigned /Driver:"C:Drivers1.inf" /Driver:"C:Drivers2.inf" /Driver:"C:Drivers3.inf"

And what'll happen next? Say, DISM would add a driver like WinVBlock to the Driver Store. Does it "reflect" it as a critical boot-time driver

Yes, boot critical drives are proper integrated. That's .inf use a relating class.

Contrary USB 3.0 driver use a non boot class.
You may use dism to include drivers, but have to set boot settings yourself.
http://reboot.pro/10...post__p__115443

In addition you may set a folder to handle all inf files

DISM.exe /image:"c:VHD" /Add-Driver /ForceUnsigned /Driver:"C:Drivers"

A example: Fix_7hdc.vbs uses dism

Dism.exe is used to include the driver.

http://www.911cd.net...ndpost&p=166359

Use dism version at relating OS version.
Use a Windows 7 dism.exe at offline Windows 7. Drivers won't integrate at offline XP.
And Windows 8 use a different driver database, CriticalDeviceDatabase is obsolete mostly.
Use a Windows 8 dism.exe at offline Windows 8.

Yep, it actually does work.

Congratulations to WinVBlock experinece.

[sambul61]

cdob

You keep public amazed by regular Registry and Driver & New Device support fixes making Windows a lot more patient OS for a regular consumer. They are getting actively integrated in popular consumer grade tools across the Boards.

Your next challenge might be to find the solution to overcome "native boot from VHD" blocking for unsupported Win7 versions. AND, to find the way to make Bootmgr & BCD transfer control not only to ntldr on HD, but also to ntldr and other boot loaders placed on VHD. Actually, the later might already be solved by SUSE Linux Enterprise devs - unless it only runs inside a VM. If yes, they possibly used VBoot Port Driver that is getting pretty popular nowadays.

[sambul61]

Absolutely nothing. Apart form how pretty a green bar would look.

I'm somewhat torn between displaying used space as a bar, used space in a "cluster map bar", or somehow both. I've done a bit of design work while pondering this question:

Wow... I see obvious MAC UI usability school in these pictures.

I just realized, the UI should be operation dependent, meaning the Green Bar combo must show content relevant to the performed task. For example, in a static state the Bar would show how full the volume is. When extending a VHD, the Bar would show operation Progress. When shrinking a VHD, the Bar would show how proposed shrink would affect the existing volume (i.e. darker overlap), while the Volume area would 1st show fragmentation picture, then ask if a user wants to Defrag the Volume before attempting to shrink it, and how it would affect shrink ability. If "YES", then Volume might show actual Defrag progress similar to PerfectDisk. The left icons might also depict or symbolize some useful info like VHD Creator. Such solution would be absolutely amazing.

[sambul61]

It can be done. There's about 5 pixels of room to the right, so if you drag right and hold, it could just keep getting bigger (that is, the other partitions would seem to be getting smaller).

Great then! But the issue of maintaining visually pleasing proportions may arise, if user wants to extend or shrink a disk or volume too much.

I used DeviceIoControl to implement the cluster view that is the precursor to a defragmentation, and have experimented a little reading the on-disk location(s) of individual files. These two steps are required before you can move the file to a new location. (You have to know where the free space is, and where all the bits of your file are.)

I'm not planning to get heavily into defragmentation, I just wanted to learn enough to see if I could move those pesky files or not.

That's too bad. I was (am) hopping you can make use of Acronis Disk Director type of dll to solve Defrag & Shrink issues.

The "trim" operation also works on Fixed VHDs. Although the word "works" maybe a mis-use of the term. It doesn't actually make a Fixed VHD file any shorter, it just alters it's footer to claim that it's shorter. So now you can have a 40 MB virtual disk with an 800 MB backing file.

What's usability of this solution? If you can fix the footer AND notify NTFS that residual sectors are now free and can be occupied by new files, that would make a lot more sense.

We really need a wiki. I want to link or display topical advice at all points in VHDD, especially when it comes to things it can't do.

That's an excellent point. Except, these pesky users won't accept "can't do" part altogether.
Though, a lot of effort might be needed to avoid some "prior art" poor projects outcome, like: The boot process: a step by step approach to booting. Its an interesting read anyway, with plenty of pics, including even Vincent van Gogh and an excurse to unfortunate destiny of Lorenso Da Ponte. That thread even led to misunderstanding between trusted partners .

Even the simplest things like "A list of all VHD manipulation and mounting tools" doesn't exist - and if does, it's likely to be out of date before long.

That's why everyone welcome to contribute to the Tools for Native Boot VHDs thread. And btw, what kind of audience can possibly offer such tools' developers the level of tech support found here?! It would inevitably be seen in the end product.


Speaking of VHD boot support in Grub4DOS, there were attempts made to enable G4D map non-contiguous file-disks and such that might be useful:

Non-contiguous map and more information in int13 handler

Experimental NTBOOTDD.SYS

I'm sure, others can possibly throw more useful links on the subject of booting non-contiguous and dynamic disks with G4D.

[sfinktah]

The icons are "identicons", they show a visually unique depiction of the VHD GUID. Their usefulness will become more apparent when combined with the BCD director, and with the display of differencing VHDs which must identify their parent.

Or simply when wondering why a copy of a VHD doesn't boot the same as the original.

[sfinktah]

I have this piece of code here, written by Kenneth Bell, which is part of a broader Virtual Disk library which I've included in VHDD... In a way, it provides the solution for defragmentation, removal of volumes, and resizing, all in one.

it's C#, so it's easy to read. Easier to read than a G4D boot entry anyway.

Spoiler

			using (VirtualDisk sourceDisk = VirtualDisk.OpenDisk(_sourceFile.Value, FileAccess.Read, UserName, Password))

			using (VirtualDisk destDisk = VirtualDisk.CreateDisk(OutputDiskType, OutputDiskVariant, _destFile.Value, DiskSize, null, UserName, Password, null))

			{

				if (destDisk is DiscUtils.Vhd.Disk)

				{

					((DiscUtils.Vhd.Disk)destDisk).AutoCommitFooter = false;

				}

				// Copy the MBR from the source disk, and invent a new signature for this new disk

				destDisk.SetMasterBootRecord(sourceDisk.GetMasterBootRecord());

				destDisk.Signature = new Random().Next();

				SparseStream sourcePartStream = SparseStream.FromStream(sourceDisk.Partitions[0].Open(), Ownership.None);

				sourcePartStream = new BlockCacheStream(sourcePartStream, Ownership.None);

				NtfsFileSystem sourceNtfs = new NtfsFileSystem(sourcePartStream);

				// Copy the OS boot code into memory, so we can apply it when formatting the new disk

				byte[] bootCode;

				using (Stream bootStream = sourceNtfs.OpenFile("$Boot", FileMode.Open, FileAccess.Read))

				{

					bootCode = new byte[bootStream.Length];

					int totalRead = 0;

					while (totalRead < bootCode.Length)

					{

						totalRead += bootStream.Read(bootCode, totalRead, bootCode.Length - totalRead);

					}

				}

				// Partition the new disk with a single NTFS partition

				BiosPartitionTable.Initialize(destDisk, WellKnownPartitionType.WindowsNtfs);

				VolumeManager volMgr = new VolumeManager(destDisk);

				string label = _labelSwitch.IsPresent ? _labelSwitch.Value : sourceNtfs.VolumeLabel;

				using (NtfsFileSystem destNtfs = NtfsFileSystem.Format(volMgr.GetLogicalVolumes()[0], label, bootCode))

				{

					destNtfs.SetSecurity(@"", sourceNtfs.GetSecurity(@""));

					destNtfs.NtfsOptions.ShortNameCreation = ShortFileNameOption.Disabled;

					sourceNtfs.NtfsOptions.HideHiddenFiles = false;

					sourceNtfs.NtfsOptions.HideSystemFiles = false;

					CopyFiles(sourceNtfs, destNtfs, @"", true);

					if (destNtfs.FileExists(@"bootBCD"))

					{

						// Force all boot entries in the BCD to point to the newly created NTFS partition - does _not_ cope with

						// complex multi-volume / multi-boot scenarios at all.

						using (Stream bcdStream = destNtfs.OpenFile(@"bootBCD", FileMode.Open, FileAccess.ReadWrite))

						{

							using (RegistryHive hive = new RegistryHive(bcdStream))

							{

								Store store = new Store(hive.Root);

								foreach (var obj in store.Objects)

								{

									foreach (var elem in obj.Elements)

									{

										if (elem.Format == DiscUtils.BootConfig.ElementFormat.Device)

										{

											elem.Value = DiscUtils.BootConfig.ElementValue.ForDevice(elem.Value.ParentObject, volMgr.GetPhysicalVolumes()[0]);

										}

									}

								}

							}

						}

					}

				}

True - it copies, rather than act on the original VHD. But that's really the fastest way to do things, and pretty much the only way to get a product that you can trust not to accidentally mangle something.

It's a stand-alone EXE if you want to try it. http://discutils.cod...ases/view/78973

From my reading of the code, it will take a VHD of any type, and make a new VHD of any type, containing the first partition of the original, at any size you specify.

There's also a PowerShell download on that page, I'm not sure if it's a UI for the toolset or not, but it might be worth checking out too.

He's really done some amazing work.

[sfinktah]

OSClone.exe -l cloned -of VHD-dynamic -sz 1GB c:big2.vhd c:big3.vhd

It shrunk an (empty) 127 GB NTFS partition (above) with the usual MFT junk at the 3GB mark, into a 1GB NTFS partition (below) in about 1 second. Obviously that would be a lot lot slower if there were files to copy.

But as you can see from the identicons, it also changed the GUID of the drive. That is obviously undesirable But you see how useful the identicons are now

[sambul61]

Interesting find with this code - will try. What's even more interesting, it was updated TODAY.

Yeah, I got identicons part by now, it sounds pretty clever. The troublesome parts are:

- the Green Bar still doesn't show how full the volume is, and possibly might even show data distribution around the volume (large empty space areas as hint to Compact);
- another thing is to depict max disk size after resizing proportionally to some degree, now they're equal on the pic. Basically, for dynamic VHDs (which seems to be Basic NTFS disks, i.e. not spanning over several partitions), current disk size will match current partition size. For fixed VHDs, actual disk size would be different for each, and can be bigger than their volume size;
- the volume size before shrinking is usually different than after shrinking, despite the amount of data on it might remain the same (if Pagefile etc. aren't deleted for shrink efficiency), so the UI should show that;
- I assume that Volumes are also resizable in UI by dragging the handle similar to VHD disks
- the UI should visually interpret the different outcome of shrinking a dynamic VHD (changing disk max size & volume size) and compacting it (compressing data & changing Volume size only). How to do it without showing each dynamic VHD at set max size?
- Thin Provisioned dynamic VHDs should be identified visually

Apparently, UI for manipulating VHDs out to be more complex and creative (possibly layered) than in current partitioning tools like ADD. The work you shown thus far reveals a top notch professional.

Also, a dynamic VHD with large amount of data would take long time to copy, while it might not be needed to shrink its max size by changing its footer, if its volume occupies only a fraction of max zise. And, to extend a dynamic VHD, all that's needed is to update its footer, why copy? There is no requirement to have enough free space available next to it or in other disk areas, unless OS must be booted from it on the same hard drive, and Thin Provisioning isn't used, or OS Bootmanager & File System don't support booting from non-continuous disk images.

[sambul61]

Speaking about testing the app in Windows Virtual PC and Hyper-V, MS posted a fix to remove HW Assisted Virtualization Requirement (HAV) from VPC, which can possibly be researched and the approach used in Hyper-V. To check, if a PC supports HAV, one can use this tool. To run Win7 in both VPC and Hyper-V, one must uninstall VM Integration Components in a running VM, and add DetectHALOn parameter to its BCD store. Running WinXP in both would require adding multiple HAL choice to Boot.ini as per wimb's IMG_XP help.

Another major issue, I forget to mention: when srink or defrag is performed, its desirable to ensure that:

- VHD images stored on a VHD being shrunk remain contiguous after shrinking to ensure booting OS from them with Grub4DOS;
- free space is left between VHDs stored on the VHD being shrunk to prevent them from become fragmented at each install of Windows Updates and other programs, as well as when a VM or PC writes large service files like Hiberfil.sys etc. onto the VHD after booting OS from it.

I кееp facing the situation, when a fixed VHD once booted from another VHD with G4D inside a VM, OS updated and then shut down, no longer boots with G4D since the VHD file becomes fragmented. To prevent it, a smart tool like VHD Director would have to leave free space btw VHDs, when shrinking disks or on user demand as a separate feature. Or possibly integrate WinContig like utility, but the trick is to shrink VHD such a way that it remains contiguous, while free space is optimally consolidated. Currently its impossible to control, when copying VHDs to a hard drive, thus the only choice left is to make them Read Only. Fortunately, OS versions supporting native boot from VHD, don't face this issue when booted with Bootmgr, since it doesn't require VHD file to be contiguous.

Of course, simpler and better solution addressing the root cause would be enabling G4D to boot OS from non-contiguous images, since tweaking Bootmgr to boot unsupported OS, or maintain image continuity at each OS shutdown sounds problematic.

[sfinktah]

Yuck. I actually tried the OSClone facility of DiscUtils out, it is OMG so slow. But watching the filenames scroll painfully by, I did get another idea:

WINDOWS$NtUninstallKB978601$kb978601.cat

WINDOWS$NtUninstallKB978601$spcustom.dll

WINDOWS$NtUninstallKB978601$spmsg.dll

WINDOWS$NtUninstallKB978601$spuninst.exe

WINDOWS$NtUninstallKB978601$update.exe

WINDOWS$NtUninstallKB978601$update.ver

WINDOWS$NtUninstallKB978601$updatebr.inf

WINDOWS$NtUninstallKB978601$update_sp3qfe.inf

WINDOWS$NtUninstallKB978601$updspapi.dll

WINDOWS$NtUninstallKB978601$wintrust.dll

WINDOWS$NtUninstallKB979309$spuninstspuninst.exe

WINDOWS$NtUninstallKB979309$spuninstspuninst.inf

WINDOWS$NtUninstallKB979309$spuninstspuninst.txt

WINDOWS$NtUninstallKB979309$spuninstupdspapi.dll

WINDOWS$NtUninstallKB979309$branches.inf

WINDOWS$NtUninstallKB979309$cabview.dll

WINDOWS$NtUninstallKB979309$eula.txt

WINDOWS$NtUninstallKB979309$kb979309.cat

WINDOWS$NtUninstallKB979309$spcustom.dll

WINDOWS$NtUninstallKB979309$spmsg.dll

WINDOWS$NtUninstallKB979309$spuninst.exe

WINDOWS$NtUninstallKB979309$update.exe

WINDOWS$NtUninstallKB979309$update.ver

WINDOWS$NtUninstallKB979309$updatebr.inf

WINDOWS$NtUninstallKB979309$update_sp3qfe.inf

WINDOWS$NtUninstallKB979309$updspapi.dll

WINDOWS$NtUninstallKB981997$spuninstspuninst.exe

WINDOWS$NtUninstallKB981997$spuninstspuninst.inf

WINDOWS$NtUninstallKB981997$spuninstspuninst.txt

WINDOWS$NtUninstallKB981997$spuninstupdspapi.dll

WINDOWS$NtUninstallKB981997$branches.inf

There's a bucket load of space that can be gotten out of removing all the crappy files. One just has to be sure how crappy they are.

[sfinktah]

Thin Provisioned dynamic

Can you clarify the definition of that?

I was showing fixed/dynamic in the form, but I temporarily switched it out to show the VHD name. I'll put it back in when I find the right layout.

Yes, the green bar need to show something, and space used is the obvious default choice (and the other ideas you mentioned in a previous post were interesting too). You're right about the cost/benefit of copying an entire disk for the sake of just a few files also... especially if it will be as slow as this tool appears to demonstrate.

I certainly love ADD, and it's obvious that's the model I used. The disparate partition sizes are because every partition (no matter how small) needs about 95 pixels (20% of the window) to show it's information. So if you have 2 small partitions, that's using 40% of the available width, and the big partition in the example (110 GB) is still tiny compared to the 2TB VHD. It's a bit of a balancing act.

I'm trying a more simplistic approach for resizing actual partitions, it's just a right click and "Resize", much like diskmgmt.msc does.

- VHD images stored on a VHD being shrunk remain contiguous after shrinking to ensure booting OS from them with Grub4DOS;
- free space is left between VHDs stored on the VHD being shrunk to prevent them from become fragmented at each install of Windows Updates and other programs, as well as when a VM or PC writes large service files like Hiberfil.sys etc. onto the VHD after booting OS from it.

Funny you should mention that. It is quite easy to do, and I had already been thinking of leaving a block of space at the start of a new VHD (say 1GB) for the operating system to put all it's extra MFT junk and pagefiles in. Reserving space at the end is also not a huge issue, but just be aware that 2 GB of reserved empty space at the end of a drive would still use 2 GB of VHD.

it's not that hard to "defragment" a VHD, such that every block is in order, and there are no blocks skipped. If you combine that with a properly defragmented filesystem, and a 2 GB end buffer... and then you contig the VHD file, that should leave you with a fairly stable VHD. Ideally you'd then set the size of the VHD to the maximum you've allocated.

But then you effectively have a fixed VHD.


With regard your XP VHD adventures, I'd be interested to see if I could boot my test VHD (the Microsoft XP IE demo) on a real PC. Since it was built specifically for running in a M$ VM, it would certainly be a good test.

[sfinktah]

Hmm thanks for the tip on the latest DiscUtils... although it's kind of anoying, since I just got through making patched to the previous version to get around some MFT bugs.

That guy sure keeps busy:

Support VMDK chains parented by a VHD.

Like. WTF?!

[bwiese]

Like. WTF?!

You can run a VMware virtual machine on a VHD, it will create a VMDK child disk as a write-back disk (leaving the original VHD untouched). Thus, the VHD is the parent of the VMDK. This is a common scenario when using VMware Player to run Windows XP Mode on Windows 7 when you can't use or just plain hate Microsoft Virtual PC. VMware Player actually has a "Windows XP Mode" just for this purpose.

[sambul61]

There's a bucket load of space that can be gotten out of removing all the crappy files. One just has to be sure how crappy they are.

There are a few critical folders that some 3rd party System Cleaners consider scrappable, such as C:WindowswinsxsManifests and C:WindowsSoftwareDistribution. Once you mess with them, many things can go wrong, especially installing Windows Updates and Service Packs, and uninstalling apps.

BUT, surprisingly, the integrated Windows Cleanup can do a thorough cleanup without damaging one's system. It makes sense to run it periodically on both OS on VHD and OS on the host drive before any Defrag or Resize & VHD Copy ops. There might be other non-aggressive apps useful as well, like Ccleaner.

[sambul61]

Can you clarify the definition of that?

Thin Provisioning of dynamic VHDs was mentioned here.

Speaking of UI Form improvements:

- Green bar can show how full the volume is, while the volume itself can show its fragmentation picture with empty zones.
- The app UI form needs to be (auto) resizable by dragging its border and possibly scrollable to resolve text visibility issues.
- Why not resize partitions by dragging handle just like resizing the whole disk for (intuitive) uniformity?

Not sure, what's the benefit of free space at the start of VHD rather than its end? However, Windows has its own habit of where to write service files like Pagefile etc. If it sees several disks, and one is disproportionally larger than the other (like a real HD), it will often place service files on it, especially if 3-4Gb isn't available for a Hiberfil.sys. But, its still needs to be clarified, what exact activity makes a fixed VHD file fragmented and unbootable next time, if enough space is present on it for temp files etc, except service files. In case of a dynamic VHD, the obvious reason may be that adjacent space is occupied by a host drive's files like another VHD, so there isn't enough room to grow nearby, but we're talking about static VHDs bootable with G4D.

It might be, Windows fragment them to defragment some other files it deems more important (like dirs) or simply a lot smaller to leave fragmented. In fact, NTFS might attempt to prevent file or free space fragmentation as new files are written, and along the way divide a large file like VHD on a few fragments to optimize space in general. Don't know, but needs further observation, why a fixed pre-allocated VHD suddenly becomes fragmented and doesn't boot anymore. What's more probable, BCD refers to a Hiberfil.sys located on the host drive, and it makes boot impossible - why? By that time the VHD is already mapped by G4D. Definitely needs further research.

Better solution seems to point towards using a smarter bootloader. You'll pass the test of running XP VHD on both real PC and inside a VM after adding multiple HAL choice to its Boot.ini, and Registry tweaks for your boot HD support (Win7 might require that too), both described in wimb's IMG_XP tool materials, you cataloged.

[bwiese]

There are a few critical folders that some 3rd party System Cleaners consider scrappable, such as C:WindowswinsxsManifests and C:WindowsSoftwareDistribution. Once you mess with them, many things can go wrong, especially installing Windows Updates and Service Packs, and uninstalling apps.

C:WindowsSoftwareDistribution can be safely destroyed with no consequences to a running system. Simply stop the Automatic Updates/Windows Updates service, delete the folder, and it will be recreated and data repopulated when/if the service is started again. For many years this was the only way to solve certain problems and the Microsoft recommended approach for resolving specific error codes. You will never harm your system deleting this folder.

[sambul61]

bwiese

Here is interesting discussion about it: WindowsSoftwareDistribution Folder Cleanup Automation.

Unfortunately, aggressive system cleanup often makes impossible to install Service Packs later. Seriously damaged Update Database often can't be repaired. Repair in part amounts to downloading the same files again. Anyone trying to do Win7 Repair Install in order to install a next Service Pack would understand this logic. However, there are plenty of discussions around the web, what should be left and cleaned up regularly.

I remember, you wanted to write a Tutorial about setting up iSCSI connection. That would be really great. I was trying iSCSI without notable success, because there wasn't any clear Guide on the web about it: Booting OS from a SAN Drive via iSCSI? A Tutorial from an experienced iSCSI user in that section would help a lot.

[sfinktah]

remember, you wanted to write a Tutorial about setting up iSCSI connection.

... and I remember you pasting me many guides to it

I'll write you a custom guide. Just tell me what you use for a DHCP server, and what options you have for a TFTP server, and an iSCSI server.

[sambul61]

I was trying to setup iSCSI for testing and future planning purposes a year ago, thus have to refresh some aspects now before asking particulars. Above I just mentioned that an overview type Tutorial written by an experienced Pro would help many, as thousands of people browse this forum daily, since iSCSI area is seldom known well.

As to the pic above, may I suggest considering a different approach: brief tips may accompany less familiar or requiring educated choice operations. The tips would include a link to a Help section, describing details of that subject. Reason for such approach is simple: people tend to grow, master daily routing over time, hence originally required info may no longer be desirable. Even the Tips might need be optional (Show Tips Select in Prefs). Also, some graphs, diagrams and pics in Help can work wonders.

[sambul61]

I was rather planning on leaving the tips and links up to you

As for iSCSI, I wasn't entirely joking when I said I could write 10 tutorials... there are so many combinations of software and hardware (or virtual hardware) that can be used to achieve the same goal without actually varying the method...

BTW - That compaction screen isn't just pretty pictures this time, it actually performs both stages of a compaction.

Congratulations with your 1st Reboot.pro iSCSI Tutorial:

Choose Your Own iSCSI Adventure


Its interesting, whether your current UI will reflect the same disk differently before and after Compaction for each case: when one, or another, or both of the operation options are selected by a user?

Another suggestion is to use different transparent background colors for different Volume File Systems, and also harmonize empty volume space background color with occupied space color (it may be the same color of lighter intensity). Would be good to also indicate, which mounted volumes contain bootable OS installs, hence can be booted from.

Here's an example of showing Volume Fragmentation in PartitionGuru (a Magnifier Glass might be added to show Sectors and Files info):

[sfinktah]

[sfinktah]

Another suggestion is to use different transparent background colors for different Volume File Systems, and also harmonize empty volume space background color with occupied space color (it may be the same color of lighter intensity). Would be good to also indicate, which mounted volumes contain bootable OS installs, hence can be booted from.

All good ideas, I've secretly tagged green for NTFS, which will look like this:

I like the graph representation in your screenshot, I went for shades, although there's just no way to show enough detail. (64 GB = 16 million clusters, or 32,000 VHD blocks, ... ).. Zoom would be easy enough though. Didn't think of that.

Bootable flags - also a good idea. I will have fun selecting an icon for that.

harmonize empty volume space background color with occupied space color

Are you referring to general design (i.e. just making sure it's pretty looking), or something specific (like having empty space represented as grey partitions - perhaps the color I'm using now) ?

I realise that the present layout doesn't speak volumes for my graphic design skill, with three different types/colors of usage/progress bars.... i just wanted to show you some options.

ANYWAY, you only have yourself to blame for these: ... it was your comment about apple/macintosh style that made me recall the progress bar from the iphone.

here are some mockups that i was playing with, but didn't go with (although I might use the gray bottom bar from the first one)






Besides pretty pictures, I also added a VHD API based "Expand" (very boring)


and context menus for the disk, and the partitions... although the partition features aren't implemented yet

[sfinktah]

rofl