Install.wim rebuild Size

[Legolash2o]

Ok firstly all the sizes are in bytes and are taken from "size on disk" reading (when you click properties on an file/folder you get size and size on disk).

I think i have figured out a way to estimate the size of the install.wim for the rebuild process because at the moment you get just whatever its done so far i.e. 345MB. But with this idea if it works it will shows an estimate i.e. "Rebuilding.... 345.17 / 1300.85MB"

Ok ive gotten the size of the VsTemp19 folder in vLite temp folder in bytes and install.wim size in bytes too after rebuild(remember using "Size on Disk")

1st Test

VsTemp19: 6,545,445,238

Install.wim: 1,558,495,232

VsTemp19 / Install.wim = 4.19 (i have rounded the decimals)

2nd Test

VsTemp19: 6,162,133,366

Install.wim: 1,463,308,288

VsTemp19 / Install.wim = 4.2

3rd Test

VsTemp19: 5,555,974,518

Install.wim: 1,306,759,168

VsTemp19 / Install.wim = 4.3

Result

The Install.wim is around 4.2-4.3x smaller than the VsTemp19 Folder

So lets say i use 4.25 (average), excel said it was 4.22 but oh well

If i made a random vlite and its VsTemp19 folder was 5,555,974,518bytes and then divide that by 4.25 i get 1,307,288,121.88bytes

for the people who cant be assed to do maths i'll divide that by 1048576 (so its in MB) = 1246.73MB

So the install.wim during the rebuild process is going to be around 1246.73MB, so on the rebuilding process it would say "Rebuilding 345.17 / 1246.73MB" (remember that its just an estimate but it will give the user an idea of how long they have to wait).

Simple Explanation

VsTemp19 / 4.25 = A

A / 1048576 = Estimated Size of install.wim

(VsTemp19 / 4.25) / 1048576 = install.wim

For Nuhi: Have to get it before vlite clears the vstemp19 folder when on the rebuild process

Conlusion(Usining 4.25 with tests 1,2 & 3)

Test1

VsTemp19: 6,545,445,238

Estimated Install.wim = 1468.76MB

Actual install.wim = 1486.30MB

Test2

VsTemp19: 6,162,133,366

Estimated Install.wim = 1382.75MB

Actual install.wim = 1395.52MB

Test3

VsTemp19: 5,555,974,518

Estimated Install.wim = 1246.73MB

Actual install.wim = 1246.22MB

As you can seeit actually works, it has pretty close like if using 4.25 test 1 is 22.46MB off and in test 3 is only 0.51MB off!!

P.S. Excel did all the calculations for me so im not a maths genius lmao

Edited November 10, 2007 by legolash2o

[nuhi]

If it is that stable prediction I'll add it and we'll see.

I just hope that size calculation does not take too long because of so many files, it usually does and I'm not willing to wait even 10 seconds extra for this cosmetic upgrade.

Just so you understand if I don't do it, thx anyway.

[Legolash2o]

size calulation when on properties takes about 3 secs, you dont need to count everyfile, just the size of the mount folder(VsTemp19). once you got the size of the folder the program would do the rest in less than a second. I can live without this feature anyway just thought i'd post my findings

EDIT If you decide not to add this idea thingy then just delete this topic

Edited November 10, 2007 by legolash2o

[nuhi]

3 seconds? It is 8 seconds on my pc, that's borderline. Maybe you got offended judging from that lame reply about deleting this topic but for my standards vLite is too slow. Not completely my fault since there is tens of thousands of files but I believe it can go faster. 10 seconds is not nothing if that feature isn't really needed. You pressed Apply, what good is it if you find out 30 seconds before how big it will be, why spend 10 seconds for the calculation. And yeah you need to get info on every file, there is no folder size option in the code.

[Legolash2o]

nah i wasnt offended at all n yep 3 seconds, slower on my other pc, but every file! no point lol , so how would u think vlite can go faster, i think its fine how it is now except the rebuild speed but its still ok and not really a big deal.

[nuhi]

64bit removal is too slow because there are double the files, gonna try multithreading but the HDDs are the bottleneck so maybe I can't help it.

[jamieo]

64bit removal is too slow because there are double the files, gonna try multithreading but the HDDs are the bottleneck so maybe I can't help it.

Would be interesting to see how multithreading helps as I recently got core2duo and noticed vLite only uses one core...