[Post 2.3] struct VolumeInfo

[cinqmilleans]

Resolved / Related Issues
The VolumeId uniquely identifies a drive. The current code does not give us access to this information.

This information is necessary to be able to keep the sizes of the folders between sessions because the disks may have changed paths (especially removable disks).

This can also be useful information to display in disk properties (to be discussed).

Details of Changes
Add the VolumeInfo structure and its asynchronous factory which uses FullTrust code to retrieve the information.

This VolumeInfo is not yet used but will be used later to store folder sizes between sessions.

Validation
How did you test these changes?

• Built and ran the app
• Tested the changes for accessibility

[gave92]

The GetVolumeInformation win32 function is available in UWP. Could it avoid having to call the fulltrust process for this?
Edit: GetVolumeInformation does not return the GUID but the Volume serial number instead.
Edit 2: GetFinalPathNameByHandle is also available to UWP and returns the GUID. <-----

[cinqmilleans]

@gave92 Did you manage to use it? I tried several months ago. We can extract several pieces of information, but the volumeid is always empty. I had found information saying that you needed FullTrust rights to access this information. I just stayed and it returns me an empty string.

[gave92]

Ah no I've havenit tested, i was just trusting the documentation ;) I can give it a go and try And I should by now know better than trusting the documentation 😂 you're right, GetFinalPathNameByHandle only works when passing "VOLUME_NAME_NT" flag which is of little interest for this purpose, the rest give "access denied error".

It looks like the only thing you can get from UWP is the "FileID" not the Volume ID. File ID might be enough for the purpose of tracking folders even if it's not guaranteed to be unique across volumes (though for file tags I'm ignoring this fact hoping that chances of collisions are low enough).

[gave92]

OK, last attempt to avoid having to use the fulltrust process for this 😆, does the following code retrieve the correct info?

var folder = await StorageFolder.GetFolderFromPathAsync(@"C:\Users\Marco Gavelli\source\repos\Files");
var extra = await folder.Properties.RetrievePropertiesAsync(new string[] { "System.FileFRN", "System.VolumeId" });
//Debug.WriteLine($"Folder ID: {(ulong?)extra["System.FileFRN"]}");
Debug.WriteLine($"Volume ID: {(Guid)extra["System.VolumeId"]}");

[cinqmilleans]

@gave92 That doesn't work either. The value of extra["System.VolumeId"] always is null, not a Guid.

[gave92]

Works ok for me in Debug (I do get a guid), not tried in Release though. Only does not work on volume root dir.
Edit: this is what I get in Release on any folder except the root folder of a drive (does not work on "C:\"):

[cinqmilleans]

Sure enough, I was using the root. I managed to get the guid with your method. It also works for StorageFile. However, it has 2 problems:

1. Drive cannot be empty.
2. It does not work with removable drives. I couldn't get it to work for a folder in my usb drives. I get this guid with the FullTrust.

For performance, I can modify the factory to only use FullTrust when needed.

[cinqmilleans]

@gave92 There are now 3 factories: FullTrustVolumeInfoFactory, StorageVolumeInfoFactory and VolumeInfoFactory. The latter uses the Storage method, but if it fails (for example if the drive is empty), it uses the FullTrust method.

[gave92]

Ouch my suggestion was in the hope to reduce code not increase it xD.
Given the two limitations you listed above and the fact that StorageFile api is not exactly "fast" anyway we might just stick with Fulltrust.
Edit: I've reverted the latest change. If you approve, this looks good to me.

[cinqmilleans]

I approve.