topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • Wednesday December 11, 2024, 11:39 pm
  • Proudly celebrating 15+ years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: df 1.0.9.1 free disk space command line utility  (Read 3694 times)

MilesAhead

  • Supporting Member
  • Joined in 2009
  • **
  • Posts: 7,736
    • View Profile
    • Donate to Member
df 1.0.9.1 free disk space command line utility
« on: November 29, 2012, 05:13 PM »
df 1.0.9.0 command line app displays free disk space in one of B KB MB GB.

That's all it does. I wrote it because when I do a dir command at the prompt it shows me the free disk space in bytes. I'm sick of counting the digits.  df shows the largest denomination of B KB MB or GB automatically.  IOW, it should never display more than 1023 B free on x:

df /?  for help. Also there's a readme.
It's a compiled AutoIt3. No .ini file or Registry entries are created.

You may get it from my Downloads page.

Jibz

  • Developer
  • Joined in 2005
  • ***
  • Posts: 1,187
    • View Profile
    • Donate to Member
Re: df 1.0.9.1 free disk space command line utility
« Reply #1 on: November 30, 2012, 11:38 AM »
This nice little tool triggered my inner geek :-*, and I started wondering about the different ways you could compute the size of something like a file or free space in KB/MB/GB, or perhaps KiB/MiB/GiB.

If you look at different file managers and other tools, you will find they sometimes differ in what they report as file size and free space. Perhaps it is not as obvious as it may seem.

Let's assume 2 decimals for simplicity -- what should we report for 1000? 1023? 1024? One KiB is 1024 bytes, so 1000 bytes should be less than one, 1023 should be less than one, and 1024 should be exactly one. But at what point should we get 1.01 KiB?

We should get 1.01 KiB when the size is greater than or equal to 1024*1.01 = 1034.24 -- so not until 1035, because 1034 is less than 1.01 KiB.

But that means that a size of 10 or below will be reported as 0.00, because 10 is less than 1024*0.01 = 10.24 :huh:.

For free space, I think it makes sense to truncate the value like this, because having 10 bytes free is not having 0.01 KiB free. For file sizes on the other hand it seems counter intuitive to report a size of 0.00, and perhaps the value should be rounded up.

Anyway, I wonder if anybody has some input on what the "correct" way of doing this is?

I made a little test program in C which imitates your tool, so I could play around with how to do it -- I hope you don't mind if I post it here :-[.

barney

  • Charter Member
  • Joined in 2006
  • ***
  • Posts: 1,294
    • View Profile
    • Donate to Member
Re: df 1.0.9.1 free disk space command line utility
« Reply #2 on: November 30, 2012, 12:49 PM »
Almost every disk reporting tool I've ever used reported space according to the units into which the disk was formatted.  A ten (10) byte file takes up just as much space as a 500 byte file - one (1) disk unit, whether that disk unit is 512 bytes, 1024 bytes, 4096 bytes, ... 

My current tool, TreeSize Pro, lets you view actual space, allocated space, and wasted space, among other things.  If I'm going to compress/archive some files, I want to know their actual space.  However, if my intent is to copy/move them, I want to know their allocated space. 

Added to the problem/confusion is that most file/disk examiners report size in binary, while disk manufacturers report disk size in decimal.

Given that, I suspect that df takes its information from the OS.  Just remember that the actual file size will almost always be smaller than the amount of disk space in occupies.

MilesAhead

  • Supporting Member
  • Joined in 2009
  • **
  • Posts: 7,736
    • View Profile
    • Donate to Member
Re: df 1.0.9.1 free disk space command line utility
« Reply #3 on: November 30, 2012, 03:01 PM »
I think the top of the thread said what it is well enough.