A question about compiling/bundling files together....

I'm kind of confused right now…

If you use my file-bundler (MSI-Maker), it just reads the filedata and writes everything into a table (it also writes down every folder in a seperate table…)

So I thought that it shouldn't make the output smaller than the original folder.

But it is the exact opposite! (for example, OneOS is about 1,23mb big…. the output is only 711kb big)

So my question is, was my thought of compiling completely wrong or did I "accidently" made "real" compiling with just THIS?

(I also noticed that as smaller the original folder is, the "compile-effect" is smaller too, for example goes 308kb into about 297kb. AND extracting the compiled file leads to the original size…)

Piorjade, on 12 June 2016 - 04:20 PM said:

did I "accidently" made "real" compiling with just THIS?

I'm guessing you meant to type compressing?

Just skimming through the code, I'm not sure it will be able to extract all the original files, not if there are subfolders within subfolders. You have this chunk around line 60:

    for _, fldr in ipairs(folders) do
        term.setTextColor(colors.lightBlue)
        if show then print(mainFolder..fldr) end
        term.setTextColor(colors.white)
        search(fldr.."/")
    end

… but what about the entries added to the "folders" table by the searches this loop performs? ipairs is only going to loop through the entries that were in the table at the time the loop started, it won't automatically recognise entries added while the loop's in progress.

Perhaps if you rigged search() to call itself the moment it encounters a new directory…?

Edit:

Actually I'm wrong, and ipairs will indeed recognise new table entries automatically.

The only other idea that comes to mind is slack space, but I wouldn't expect that to be so significant unless you were working with a great deal of files.

Bleh. Too late at night.

This is very interesting…
If I try to compress a real .exe (I tried the lol.launcher.admin.exe from LoL) it INCREASES the size and if I extract it again, the .exe is broken. (obviously, I think?)

Anyways, thank you for your reply.

Piorjade, on 12 June 2016 - 04:20 PM said:

(for example, OneOS is about 1,23mb big…. the output is only 711kb big)

Testing things out, I find that OneOS is actually only ~600kb… but if you add the ~710kb file your archiver creates out of it, then yeah, you get ~1.27mb altogether.

Piorjade, on 12 June 2016 - 05:14 PM said:

If I try to compress a real .exe (I tried the lol.launcher.admin.exe from LoL) it INCREASES the size and if I extract it again, the .exe is broken. (obviously, I think?)

This is due to certain assumptions made when opening files in text mode. If you want to handle "any" data, you need to use file handles set to binary mode.

Well I don't know what that means but if you look at my screenshot, you see that OneOS is indeed around 600kb big but it says 1,23mb under it (Size on the hard-disk… that's how it is translated into english, am I wrong?). The "compressed" file is on both ~700kb big. Sorry that I'm that kind of a noob but I would be thankful if you could explain that to me :P/>



EDIT: Actually I found it out, I guess? It has to do something with my filesystem, in short. Well theoretically my program DOES compress, at least on NTFS/Windows (I only tested this on my Windows7 machine tho), is that right? :huh:/>

It doesn't compress. The "size" property is the number of bytes the file contains while the "size on disk" property is the number of bytes the file is taking up on the actual drive. You can read about this more here. Basically the actual file size increases but it takes less bytes to store one bigger file than a bunch of small files.