Hacking WBFS File System/File Manager oddity...

[zektor]

I had an extra USB drive laying around and decided to back up all of the current isos on my mainly used drive to it, just as a good measure. I used WBFX Manager 3.0.1 and copied 49 images from one drive to the other, and initially everything appeared to be normal. Until I checked file sizes.

The 49 images on my main drive equal to a little over 77GB. The 49 images copied to the backup drive is just a little over 75GB! I also noticed that each and every image copied to the backup drive is just slightly smaller than the image on the original source drive. For example, something like "Billy the Wizard" is reported on the source drive as 0.10GB, and on the destination backup drive as 0.09GB.

So, I extracted the ISO drive the main drive of this particular game, removed it from the backup drive, and went to re-add it. Again, 0.09GB reported (even before adding).

BUT, if I take the exact same iso extraction and apply it to add (I didn;t add it, just loaded it into the add queue), it reports as 0.10GB!

For what it's worth, they both load off of both drives, so I guess that it is fine.

But the real question is WHY the drastic change in file size between one drive and another? The main drive is a 500GB, and the backup drive is a 250GB. Could it be cluster size? I don't know for sure exactly HOW WBFS is managing the file system, so I am in the dark here. Just curious. If anybody knows, please fill me in!

 

[cheesyPOOF5]

Well, the reason the ISOs went from 77GB to 75GB is because the program that transferred the ISOs trimmed off garbage data to decrease filesize. The extremely small size being reported is probably just a program error.

 

[zektor]

Actually, this has to be incorrect. I find it very hard to believe that WBFS manager would trim an ISO being sent to a drive, and then trim it AGAIN when clones to another drive. By this rationale you can keep transferring and trimming forever

They were already trimmed when they were in the process of being transferred to my original drive. The file size differences are not only reported in WBFS manager, but in Waninkoko's USB loader when accessed on the Wii. Something is different between drive structures (sizes) in how the WBFS file system handles them. They are slightly larger (in my experience) on larger drives. Can anyone else confirm? Perhaps copy the exact same ISO to a large USB drive and a smaller USB drive and compare?

 

[Deleted-171178]

WBFS uses a different process to store the Isos and "Scrubs" them to trim off as much data as it can and stores them more efficiently than NTFS or Fat.

 

[zektor]

WBFS uses a different process to store the Isos and "Scrubs" them to trim off as much data as it can and stores them more efficiently than NTFS or Fat.

No doubt that it does. But what I am saying is that if you transfer a 4.7GB standard ISO to a 500GB usb drive using WBFS manager and your transferred file size (after scrubbing) is say...1.67GB....why would it be that when you use the SAME program and transfer the SAME ISO to a 200GB usb drive the final product after scrubbing would be 1.65GB?

I don't care about the fact that the games work, but what I am trying to find out is why the file size discrepancy? After a multitude of ISOS being transferred, you can see that space is being more conserved on one size hard drive and apparently wasted on another.

 

[Deleted-171178]

I don't know why the size would drop if you transferred to a different hard drive.
It seems like its a pretty cool "Bug"

 

[zektor]

I don't know why the size would drop if you transferred to a different hard drive.
It seems like its a pretty cool "Bug"

Hehe

It would seem if this IS a bug, it is a bug in favor of smaller HD owners. As the same amount of games on my 250GB is taking 2GB LESS than the same amount on my 500GB!

I still tend to believe that it has to do with cluster sizes and how WBFS is handling them, but I guess I will not know until I get in touch with the author of WBFS manager or Waninkoko himself

 

[redia]

if I am not mistaken it is not a bug.
it is a feature.
if you look at the WBFS estimate feature you will figure out what I mean.

exactly like fat/fat32... when you create a WBFS partition you end up with what could be considered as clusters... so depending on the size of your partition.. you get a different number/size of cluster.

this explains why on two different partitions the size of the game will not be exactly the same.
you should also consider the rounding..
I did not check the rounding mecanism on wbfs estimate function.
but 0.094 could be rounded down to 0.09
while 0.096 could be rounded up to 0.10

so a slight difference on the cluster size will create a different sizegame. but let's face it.. it is always better than keeping over 4go for each game

in Windows you have the possibility of seeing the "real size" and the "size used on disk"...
on WBFS you get the "size used on disk"...

Cheers,
R

 

[zektor]

if I am not mistaken it is not a bug.
it is a feature.
if you look at the WBFS estimate feature you will figure out what I mean.

exactly like fat/fat32... when you create a WBFS partition you end up with what could be considered as clusters... so depending on the size of your partition.. you get a different number/size of cluster.

this explains why on two different partitions the size of the game will not be exactly the same.
you should also consider the rounding..
I did not check the rounding mecanism on wbfs estimate function.
but 0.094 could be rounded down to 0.09
while 0.096 could be rounded up to 0.10

so a slight difference on the cluster size will create a different sizegame. but let's face it.. it is always better than keeping over 4go for each game

in Windows you have the possibility of seeing the "real size" and the "size used on disk"...
on WBFS you get the "size used on disk"...

Cheers,
R

Thanks for the info. This clears it up for me. I now understand what you are talking about...thanks!

You know, so many people now using WBFS not really even caring about the file system structure and how it works, but I am pretty interested. Seems to be pretty solid...I wonder if it fragments