Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

WAD Free issue

Code:
D:\>free c: d:

 Volume in drive C is unlabeled      Serial number is 6248:0def
   214,819,663,872 bytes total disk space
   162,726,023,168 bytes used
    52,093,640,704 bytes free
              75.8 % in use

 Volume in drive D is DATA           Serial number is 4a67:f149
   214,819,663,872 bytes total disk space
   162,726,023,168 bytes used
    52,093,640,704 bytes free
              75.8 % in use

D:\>cdd c:\

C:\>free c: d:

 Volume in drive C is unlabeled      Serial number is 6248:0def
   104,864,092,160 bytes total disk space
    98,079,625,216 bytes used
     6,784,466,944 bytes free
              93.5 % in use

 Volume in drive D is DATA           Serial number is 4a67:f149
   214,819,663,872 bytes total disk space
   162,726,023,168 bytes used
    52,093,640,704 bytes free
              75.8 % in use
Notice how the C: drive reports different amounts of space between the two calls. In the first call to free, the current folder on C: happened to be a junction pointing to a folder on D:. So, instead of reporting the space for C:, it reported the space for D:. In the second call to free, it was done at the root of C: and not within a junction to D:. Thus, it reported the expected values.

Per the help, the parameter is supposed to be a drive letter, not a folder path. Thus, when specifying just the drive letter, I would have expected the values of C:\ instead of C:\junction=>D:\folder. Instead, it appears to operate on drive letter only for the label and serial number, but on the (implied?) folder path for the space calculations. I get similar differences for "free C:\junction" vs "free C:\". Should folder paths even be allowed? They are certainly undocumented. Either the help or the result is incorrect. What is the intended behavior?
Code:
C:\>ver /r

TCC  17.00.71   Windows 7 [Version 6.1.7601]
TCC Build 71   Windows 7 Build 7601  Service Pack 1
 
Folder paths must be allowed as volumes can be mounted anywhere, not just as the root, so different folders can easily represent different size sizes, including total and free space.

If anything, this is a documentation bug, the documentation likely predates the time when it was possible to mount a volume within another volume.
 
I agree about the folder path support, which does currently work. My issue is that drive letter isn't guaranteed. Given the documentation, I expected having just the drive letter to be equivalent to the root of that drive, i.e. C: == C:\, and not the current folder on that drive, which could be a different drive entirely. In the case of using the other drive (C:\junction => D:\folder), the drive label and serial number are still for C: and not for D:. Part of the data reported is for the (expected) drive letter while another part is for the target drive of a junction. It's inconsistent. If it is going to report a different drive than that referenced by the parameter, there should be some indication of that. For example, the output could be like this:
Code:
D:\>free C:\Junction

Junction: D:\folder

Volume in drive D is DATA           Serial number is 4a67:f149
   214,819,663,872 bytes total disk space
   165,437,747,200 bytes used
    49,381,916,672 bytes free
                77 % in use
If the path is a link or junction to another drive, that should be indicated and the data reported should be for that other drive, both the first info line as well as the space usage report. This might allow C: to report C:\[current folder] instead of C:\ and still provide an expected output.
 
Is it intended that the drive label and serial number NOT match the space data displayed or is that full set of data returned by the API? Is there harm in detecting that what was requested was a junction and showing that target folder information before (or after) the data returned by the API (or with an optional parameter I can add to a free override alias)? I'm not disagreeing with the clamor to show "real" drive for junctions, but I do disagree with not knowing that is what is happening when I specify just the drive letter. I guess help should be updated to reflect what is really happening.
 
It's not TCC doing that. TCC is calling the Windows GetDiskFreeSpaceEx API with the argument "C:", and Windows is interpreting that as a request for the current directory info.

I'm loathe to override the default Windows behavior here. But you can force the explicit disk by doing a "FREE c:\".
 

Similar threads

Back
Top