obtaining the correct filesize as seen in explorer

[vhelp]

hi. i've been agonizing over this for a while now. i want to show the same filesize as reported by explorer, and i know that it does things a little differently, but i can't seem to figure out how it reports the filesize.

i want to report the same filesize that everyone else see's in explorer. i don't want the exact numbers, i can do that correctly for all the other examples except for explorer's.

take for example the following:

video.1.3.165.1.log (1,400 KB) <-- explorers
right-click on file, select properties, select General tab: 
1.36 MB (1,433,466 bytes)
1.36 MB (1,433,600 bytes) 

video.1.3.165.1.csv (13 KB) <-- explorers
right-click on file, select properties, select General tab: 
12.1 KB (12,428 bytes)
16.0 KB (16,384 bytes)

video.1.3.165.1.hevc (607 KB) <-- explorers
606 KB (620,678 bytes)
608 KB (622,592 bytes)

and, here's another view in list format:

Explorer   properties Size               properties Size on disk
1,400 KB     1.36 KB (1,433,466 bytes)     1.36 KB (1,433,600 bytes)
   13 KB    12.1  KB (12,428 bytes)       16.0  KB (16,384 bytes)
  607 KB   606    KB (620,678 bytes)     608    KB (622,592 bytes)

i can't tell if it is a rounding thing or something to do with hdd custer sizes for different hdd's or windows os version, and so on. i'm confused. thanks for any help to solve this.

[El Heggunte]

Yes, the ACTUAL filesize and the "EFFECTIVE" filesize will be the same thing
only when the actual filesize is a multiple of the cluster size

What's the problem, then?

[vhelp]

i can produce the (48.249 bytes) but not the 47.1 KB which would still be different in explorer view. i want the one that explorer shows because that is what everone see's. well, that is what i see. i never look at the 47.1 KB or the 48.249 bytes. i look at the rounding version that explorer uses or whatever fancy method it is using.

for instance, take a look at the the following from my first post:

607 KB 606 KB (620,678 bytes)

the weird trickyness that explorer is using. i dont understand why it uses 607 KB instead of 606 KB when you compare the huge different with 620,678 byte (or, 620 KB)

[jagabo]

i can produce the (48.249 bytes) but not the 47.1 KB

48249 / 1024 = 47.1

[vhelp]

i meant el heggunte's explorer 47.1 version which he did not show.

i am using xp home sp3, maybe w7 and greater are different views ? maybe they are using the exact number, thus 47.1 but i don't know.

anyway, i thought some more about it and i think i finally figured out what or how explorer is doing it. someone more savy than i can probably correct me with the proper terms in these things.

take for instance the following:

text.txt      1    KB <-- explorer
        Size: 1    by (1 bytes),
Size on disk: 4.00 KB (4,096 bytes)

now let me try to explain as best i can and someone can correct with the proper terms if they are familiar with these things.

because my minimum cluster size for my os and hdd settings is 4096, that 1 byte file is actually 4096 bytes or 4.96 KB, but explorer wants to display everything in KB, which is fine by me. and the cluster are internal to the hdd and we really want the true size of the file not the file+minimum_custer (though still true) and to add to that confusion, explorer wants to display everything in KB, thus, to get at explorers reportable minimum, it has to report 1 KB as the size.

therefore, it seems that whatever is the nearest KB, but still being within the custer size (4096) but below it, explorer will round to the nearest whole KB but that is closest to the 1 byte size, which make it 1 KB not 4 KB.

now, all i need is the formula(s) to produce the same thing.

[El Heggunte]

Micro$oft is notorious for some weird decisions, and I'm not sure if "complying" with them would be a wise move

Anyway, and FWIW:

if I change Explorer's view from "List" to "Details", then the size column says 48kB,

BUT the status bar keeps saying 47.1kB

BTW, on my XP machine, all disks were formatted with cluster_size == 1kB.

[vhelp]

yeah, i figured it out, bam-what ?#!
i just need to figure out how ms is rounding or rounding to nearest what? since it is off by 1k plus some decimals. come on, i'm two fingers close.

anyway, your 47.1kb in the status area is correct, mine reports similar. i would double-check your custer_size to be sure it is 1k. you can use checkdis /i /c for that info. it will report it as 'allocatin units' so i guess that is the correct term, or AU. anyway.

[Cornucopia]

What kind of decisions are you making to where you need to worry about your minor differences from MS's reporting?

Certainly cluster size variations won't bear much weight with bitrate determinations on multi-Gigabyte video files.

Iiwy, I would do an exact calc using proper 1024 scaling factors, etc., and live with it. I certainly don't rely on MS's accounting for something that's critical.

Scott

[vhelp]

i agree with you, and i maintain the exactness elsewhere when needed. but for my needs, the exact size is not needed, just the explorer. i am accustomed to the explorer view and i want to mirror it for my use. this whole thing has been a mystery to me for some time and i revisited it on occassions but did not act on it during those times. this time i acted and decided to solve it once and for all ! well, i'm just a noise hair between two fingers closer to the final answer.

[El Heggunte]

i would double-check your custer_size to be sure it is 1k.

Of course it's 1024 bytes, because Windows's default settings are STUPID,
µ$oft doesn't know there is no such thing as "best for everybody"

[C:\]
=>format /?
Formats a disk for use with Windows XP.

FORMAT volume [/FS:file-system] [/V:label] [/Q] [/A:size] [/C] [/X]
FORMAT volume [/V:label] [/Q] [/F:size]
FORMAT volume [/V:label] [/Q] [/T:tracks /N:sectors]
FORMAT volume [/V:label] [/Q]
FORMAT volume [/Q]

<snip>

  /A:size         Overrides the default allocation unit size. Default settings
                  are strongly recommended for the culturally-deprived :-P

                  NTFS supports 512, 1024, 2048, 4096, 8192, 16K, 32K, 64K.
                  FAT supports 512, 1024, 2048, 4096, 8192, 16K, 32K, 64K,
                  (128K, 256K for sector size > 512 bytes).
                  FAT32 supports 512, 1024, 2048, 4096, 8192, 16K, 32K, 64K,
                  (128K, 256K for sector size > 512 bytes).
                  exFAT supports 512, 1024, 2048, 4096, 8192, 16K, 32K, 64K,
                  128K, 256K, 512K, 1M, 2M, 4M, 8M, 16M, 32M.

                  Note that the FAT and FAT32 files systems impose the
                  following restrictions on the number of clusters on a volume:

                  FAT: Number of clusters <= 65526
                  FAT32: 65526 < Number of clusters < 4177918

                  Format will immediately stop processing if it decides that
                  the above requirements cannot be met using the specified
                  cluster size.

                  NTFS compression is not supported for allocation unit sizes
                  above 4096.

<snip>

[jagabo]

A file has an exact size in bytes. Windows Explorer shows file sizes in KiB, Mib, GiB (they don't use the "i" nomenclature). A KiB is 1024 bytes. A MiB is 1024*1024 (1,048,576) bytes. A GiB is 1024*1024*1024 (1,073,741,824) bytes. Since they don't use decimal points the value is rounded up to the nearest integer when showing KiB, MiB, or GiB.

Files are stored on disk in clusters (oka allocation units). Cluster size varies depending on how the drive is formatted, as El Heggunte showed. A cluster can only be used by one file. So a file that's not an integer number of clusters in length removes more space from the disc than it's true size. The "size on disk" report includes that partially filled cluster at the end of the file. So, with 4096 byte clusters, a 4096 byte file consumes one cluster worth of disk space, but a 4097 byte file consumes 2 clusters (8192 bytes).

[vhelp]

yep, thats what i understood now. you express it much better, as usual, thanks.

i also would like to say that i finally solved the m$ way earlier at work but wanted to wait on reporting that until i had time to revive an old search project, something i use at work and home when i want to quickly search for something without disturbing the folders since sometimes *all* the folders mysteriously get refresh and whatever listings i had displaying in folders (at their positions) get resorted to the top. i hate that annoyance. anyway. i actually prefer the KB only because everything is one prefix not multiples of by kb mb gb etc. i think i can understand why m$ choose the KB as the major prefix in explorer folder file listings.

[hello_hello]

If I read a thread where someone's commented on a Windows Explorer annoyance, I try to recommend using xplorer2 instead. Once you have, you'll never go back......

Imagine two instances of Windows Explorer running side by side (for easy copying and pasting etc). Then give each instance of Windows Explorer tabs like a browser. That's how I run xplorer2. But you can run it like the traditional Windows Explorer view if you want to. Once you set it up you can save the configuration so it opens the same way each time.

Even the free version is fairly configurable. Each tab can be configured individually. Different columns, details view for one tab, thumbnail view for another. I'm so used to navigating with xplorer2, I find going back to Windows Explorer quite frustrating. Just the little things, like being able to double click on an empty space in one of the panes to navigate up one folder level.

Xplorer2 does display file sizes differently to Windows Explorer. You can choose to display them as bytes, or it'll use kB, Mb or GB as appropriate. It doesn't always round as much. Xplorer2 might display 426.1kB as a file size. Windows Explorer would display 427kB.