Jump to content

How to get the allocated file size?


Recommended Posts

Partition size: 5,251,072 bytes (5 MB)

Cluster size: 4096 (Default NTFS)

AutoIt Script size: 172,032 bytes (On Disk)

Other files on partition: System Volume Information directory (0 bytes size)

Total number of empty byte files created: 1762

Free space remaining on drive: 4096 bytes

So, its possible to fill a drive up with 0-byte files but not due to the size of the file itself but because it fills up the MFT and the MetaData sections of the partition.

Here's the script I used:

Global $i

Main()

Func Main()
    HotKeySet("^!+x", "Quit")
    While 1
        Local $hFile = FileOpen("test" & $i & ".txt", 1)
        If $hFile <> -1 Then
            FileClose($hFile)
        Else
            ExitLoop
        EndIf
        $i += 1
    WEnd
    Quit()
EndFunc

Func Quit()
    MsgBox(4096, "", "Iterated: " & $i)
    Exit
EndFunc
Link to comment
Share on other sites

@blindwig

why use _ceil ? ceiling is better.

<{POST_SNAPBACK}>

What's the difference between the two? The first thing I notice is that _Ceil(0) returns 1 where Ceiling(0) returns 0.

Also, what version was ceiling() added? It's not in my SciTE definitions nor is it in my help file. How do I get those 2 things updated? I used the install package for beta 61, does that not update those things?

Link to comment
Share on other sites

On (at least NTFS), a 0-byte file is only stored in the MFT.  There is no actual hard disk space used and the file will be 0 bytes until the first character is added, then it will obtain disk space to be stored.

<{POST_SNAPBACK}>

Ah, you're right. I was doing my testing on ext3 and XFS file systems which seem to allocate a minimum of 1 block for a file.

Hmm... so that just make it more complicated. Now I have to detect the file system...

OK, a quick check tells me that a 0k file has no allocated blocks on FAT12, FAT16, FAT32, or NTFS5 systems. So if I wanted to take a best guess (since AutoIt runs only on MS systems and all MS FSs seem to have 0k allocated for 0k files) then it would be safe to assume that 0k files have 0k allocated.

Link to comment
Share on other sites

Well, technically speaking, they do take up something because at least the name/location is stored in the Master File Table.  So assuming you wished to take the time, I suppose it's theoretically possible that you could create enough 0 byte files to fill the MFT causing it to expand and expand until it used up the entire hard drive.  However, I would suspect that it is not possible for the MFT to do that, there is surely a cap on its growth size.  Also, I would argue that the 0 byte files are not what is filling the hard drive up but rather the information being used to record their existence.  So I would say that you could fit as many files as you had: BytesFreeSpace / SizeOfFileEntryInMFT = NumberOfZeroByteFiles.

I'm intrigued by this...

<{POST_SNAPBACK}>

Reminds me of a bug I once found in DOS (versions previous to 5.0) where if you fill up the drive by making directories, the last directory that you make will exist in the file table, but since there is no more room for a full entry, it will point back to the root directory.

A neat trick, but I could never figure out anything useful to do with it, other than breaking recusive file searching routines...

Link to comment
Share on other sites

Hi everyone,

I read some of the post regarding allocated size. I'm interested because I might need it in the future say monitoring. What is the benefit of getting the allocated size of a file?

Thanks,

N

<{POST_SNAPBACK}>

It's useful for calculating how much space has been consumed on a drive. Because of allocation units, many small files on a drive actually take up more space on a drive than 1 big file - often even the the big file is bigger than the sum of the small files.

I'm writing a routine to help me keep my drives clean, and I've got a routine that recursively travels the drive and returns a sum of all files from a given parent folder. But I want to return both numbers - the size of the data in that folder, and also the amount of allocated space consumed by that folder. The first number is useful in determining how much useful data is in the folder, and the second number is useful for determining the cost of storing that data.

Link to comment
Share on other sites

Reminds me of a bug I once found in DOS (versions previous to 5.0) where if you fill up the drive by making directories, the last directory that you make will exist in the file table, but since there is no more room for a full entry, it will point back to the root directory.

A neat trick, but I could never figure out anything useful to do with it, other than breaking recusive file searching routines...

<{POST_SNAPBACK}>

What I thought was interesting about my test was I expected the drive to be pretty much nothing but MFT. That was not the case, though. Most of the drive was actually meta-data and also there was a significantly large portion of it devoted to "Directory" even though there was only one directory (System Volume Information). I created all the files in the root of the drive (Which I had mounted as an NTFS folder).

It was kind of fun filling a drive with 0-byte files, though.

Link to comment
Share on other sites

It was kind of fun filling a drive with 0-byte files, though.

<{POST_SNAPBACK}>

Reminds me of the first generation of Unix viruses, which filled up the inode tables by recursively creating 0 byte files / directories - you could be unable to create a file on a drive that showed it was virtually empty and you had root permissions for.

Reading the help file before you post... Not only will it make you look smarter, it will make you smarter.

Link to comment
Share on other sites

It was kind of fun filling a drive with 0-byte files, though.

i bet, when i first saw the question about how many it would take, i decided that when i'm off of work (since i can't do it to one of their hd's) i was gonna go home and throw in a crap drive to fill it, but you beat me to the punch... may still do it but probably not....

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...