LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Get Folder's Size on disk (not size)

I'm trying to get the Folder's "Size on disk". It's working with "du.exe" using "System Exec.vi".

I don't want to use System exec.vi as it increases dependency.

DLLs, .Net Constructors, Property nodes etc is fine.

OS and S/W Info: Windows 10 - 64 Bits and LabVIEW 17.

Note: You can find all details related to du.exe here.

Please suggest an optimized and correct way of implementation.

 

2018-02-22_1537.png

Message 1 of 10
(4,872 Views)

There is a VI called "Recursive File List.vi" in the advanced palette of File I/O. It gives you a list of all files in a directory and its subdirectories. Iterate through this array and accumulate file sizes.

Greets, Dave
0 Kudos
Message 2 of 10
(4,862 Views)

Dave, Thanks for your immediate response.

I tried the way you suggested but its giving me only Size of Folder whereas I want "Size on disk" of that particular folder.

0 Kudos
Message 3 of 10
(4,844 Views)

List Files recursively.png

Did you try this?

Greets, Dave
Message 4 of 10
(4,828 Views)

The problem is that Size on Disk depends on the block size of your drive, which can vary between drives.  There may be some low level OS calls that can return the block size.  Do a search for "get file size on disk" and see what you come up with. 

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
Message 5 of 10
(4,814 Views)

Dave,

Yes I tried same snippet. I'm getting "Size" of folder, but not getting "Size on disk". Does "Recursive File List.vi" doing anything different which will provide me "Size on disk"?.

According to my observation its same like using list folder.vi, building file paths and after that we are using same "get file size" function to get the size and then adding it together to get overall size. 

0 Kudos
Message 6 of 10
(4,780 Views)

Try this:

 

https://msdn.microsoft.com/en-us/library/windows/desktop/aa364930(v=vs.85).aspx

 

Description seems to indicate it will get actual used bytes of hard disk for a file.  Some debate about it though, but saw no resolution if it works on uncompressed files.  Again, the description seems to indicate it will.

 

If that doesn't work this will give you the cluster size for the hard drive:

 

https://msdn.microsoft.com/en-us/library/aa364935(VS.85).aspx

 

You'll then have to get the size of each file and round up to the nearest round count of that cluster size, adding them up as you go.

 

Matthew

Message 7 of 10
(4,767 Views)

"Recursive File List.vi" just gives you conveniently the path to all files in folders and subfolders. The key is "get file size" to add up the single sizes.

There is the advice to round up to next cluster size for each file, but this doesn't work for me either. To illustrate this:

 

Disk Usage Windows-Dlg.png

Windows Calculation of File Sizes & Disk Size

 

Disk Usage fsinfo.png

fsutil information with 3 different cluster/sector sizes

 

Disk Usage FP 1.png

result of disc usage calculation for 3 cluster/sector sizes, none of them match the value in the first image, but file size sum does

 

Disk Usage Diagram 1.png

The code

 

This gets confusing...

Greets, Dave
0 Kudos
Message 8 of 10
(4,752 Views)

The reported size on disk can be divided by no power of 2 bigger than 16.

Quite peculiar. I tried with several local and network folders: sizes are all divisible by 512.



Disk Usage Windows-Dlg.png

Windows Calculation of File Sizes & Disk Size



 

Paolo
-------------------
LV 7.1, 2011, 2017, 2019, 2021
0 Kudos
Message 9 of 10
(4,741 Views)

@atul_ghumade wrote:

I'm trying to get the Folder's "Size on disk". It's working with "du.exe" using "System Exec.vi".

I don't want to use System exec.vi as it increases dependency.

DLLs, .Net Constructors, Property nodes etc is fine.

 

 


Wait.  What?  You don't want to use your working solution because it increases dependencies... but you're ok with creating a dependency on a dll?  Stop being silly and use sys exec.  There's no reason to use a more complex dependency when you already have something built into LV that works for your need.

Message 10 of 10
(4,728 Views)