Get Volume Info, but of which volume?

[ThomasGutzler]

Hi,

 

On my windows machines I'm using the Disk Management to assign a mount-point folder path to the drive I'm storing data. Then I'm using "Get Volume Info" to find out how much space is left on my data disk before acquisition.

Today I learned the hard way that this doesn't do what I expected:

My data disk "DVT Results", which can be accessed via C:\DVT_Results\ has 31.56GB free space but "Get Volume Info" reports 804.22GB, which is how much space is free on C:\

 

Bug or feature?

[PiDi]

Doc, just for reference:

 

 

Returns information about the volume containing the file or directory specified by path, including the total storage space provided by the volume and the amount free in bytes.

 

IMO, it shows the volume of the drive containing your folder, so it works right. The fact that it is mounting point doesn't matter, because it still logically belongs to drive C.

[crossrulz]

My data disk "DVT Results", which can be accessed via C:\DVT_Results\ has 31.56GB free space but "Get Volume Info" reports 804.22GB, which is how much space is free on C:\

I've never heard of saying that a folder has X free space.  It is always determined by the volume.

 

But since your folder is pointing to a folder on the C drive, the Volume should be C:\ and it is telling you how much space is available on that disk.  It is working perfectly.

[shoneill]

Junction points like this create all kinds of problems, even for MS programs.  I remember trying to back up a drive with a sub-folder pointing back to the root folder.  MSBackup did NOT recognise this and tried to back up an infinite amount of data.  I don't think it's finished yet.

[ThomasGutzler]

I've never heard of saying that a folder has X free space.  It is always determined by the volume.

 

But since your folder is pointing to a folder on the C drive, the Volume should be C:\ and it is telling you how much space is available on that disk.  It is working perfectly.

 

I wasn't saying folder has X free space, I said disk has X free space and disk can be accessed via a mount-point that isn't a drive letter.

Maybe I was expecting too much from MS for a function that is so obvious in unix land.

[hooovahh]

Maybe I was expecting too much from MS for a function that is so obvious in unix land.

Probably this.  You'll probably need to use some kind of system function to get the origin path of the junction point, and then get the free space on that path.

[Phillip Brooks]

Maybe you can use this to resolve the path?

 

https://decibel.ni.com/content/docs/DOC-13708

[ThomasGutzler]

Kernel32.dll GetDiskFreeSpaceEx() does the trick

 

GetFreeDiskSpaceEx.vi

[Rolf Kalbermatter]

Hi,

 

On my windows machines I'm using the Disk Management to assign a mount-point folder path to the drive I'm storing data. Then I'm using "Get Volume Info" to find out how much space is left on my data disk before acquisition.

Today I learned the hard way that this doesn't do what I expected:

pic.png

My data disk "DVT Results", which can be accessed via C:\DVT_Results\ has 31.56GB free space but "Get Volume Info" reports 804.22GB, which is how much space is free on C:\

 

Bug or feature?

 

The problem is that you are using reparse points (the Microsoft equivalent, or more precisely attempt to create an equivalent, of unix symbolic or hard links). And that reparse points where only really added with NTFS 3.0 (W2K) but Windows itself only really learned to work with them in XP sort of, and even in W7 support is pretty limited and far from getting recognized properly by many Windows components who aren't directly part of the Windows kernel.

 

LabVIEW never has heard about them and treats them logically as whatever the reparse point is used for, namely either the file or directory they point at.

 

LabVIEW for Linux and Mac OSX properly can deal with symbolic links (hard links are as far as applications are concerned anyhow fully transparent). On Windows LabVIEW does actually support shortcuts (the Win95 placebo for support of path redirection) but does not offer functionality to allow an application to have any influence on how LabVIEW deals with them. When you pass a path that contains one or more shortcuts to the File Open/Create or the File/Directory Info function, LabVIEW automatically will resolve every shortcut in the path and access the actual file or directory. But it will not attempt to do anyhing special for reparse points and doesn't really need to as that is done automatically by the Windows kernel when passing a path to it that contains reparse points.

 

It only gets complicated when you want to do something in LabVIEW that needs to be aware of the real nature of those symbolic links/reparse points, such as the OpenG ZIP Library. And that is the point where I'm currently working on and it seems the only way to do that is by accessing the underlaying operating system functions directly, since LabVIEW abstracts to much away here. But it shouldn't be a problem for any normal LabVIEW application as long as you are mostly interested in the contents of files but not the underlaying hierarchy of the file system.

 

Incidentially my tests with the List Folder function showed that LabVIEW properly places the elements that point to directories (reparse points, symbolic links and shortcuts) into the folder name list, while elements that point to files are placed into the filenames list. And that is true for LabVIEW versions as far back as 7.0. But there is an exported C function FListDir() which is even (poorly) documented in the external Code reference online documentation, that returns shortcuts as files but also returns an extra file types array which indicates them to be of type 'slnk' for softlink which was the MacOS signature for alias files. Supposedly List Folder uses internally FListDir() to do its work and properly process the returned information to place these softlinks into the right list. Unfortunately FListDir() doesn't know about reparse points, something quite understandable if you realize that even Windows 8 only has one single API to create a symbolic link. If one wants to create hard links or retrieve the actual redirection information of the symbolic or hard link, one has to call directly into kernel space with pretty sparsely documented information to do those things.