Almost there, another test, no responses from previous test I guess everything is okay, anyways.

From this test, I managed to make archive splits restoration (wasn't easy making code for this and as of yet, it needs some tweaks for perfections)

What you must test is whether:
* The state of the input directory is the same as restore directory, I mean things like when the file was created, was the file hidden, read only, system file etc.
* Restoration is a success with CRC matching

What you must make sure:
* Make sure you don't have a 0 byte file in the directory, I haven't considered those files quite yet.
* Make sure you have more than 1 file in the directory. (Been getting errors if there is less than 2 files)

Take note:
The method used here is 4x4, just wanted to make test is as quick as possible.
Split size is set to 200MB

What to do to run test:
Put files in input folder
play with the input a little bit, hide some folders and files, play with dates and etc, also use Unicode characters on some of the files, e.g. Greek letters.
Run pack.exe then wait till it finishes
Check output directory to see the splits.
Run unpack.exe then wait till it finishes
Compare input folder with restore folder

Here all went fine I guess.

One thing only, not sure does it matter though:

On the 1st pic as you can see, for D2game.dll Date modified is different in restore folder, though it is the same file without any change on it.

On the 2nd pic if my D2game.dll is set as read-only it will get new date, any file extension set as read-only will get new date, is that supposed to work like that, you will know more for sure. :)

I also have Itemdesc.dll set as hidden and date doesn't change.

I also tested with letters čćžđš and with θωερτψυιοπλκςηγφδσαζχξωβνμ and all worked fine.

https://s32.postimg.org/i7dowz6b9/image.jpg

https://s32.postimg.org/unf04gp11/image.jpg

For CRC I guess I can use winrar:

https://s31.postimg.org/r1h95rojv/image.jpg

Thanks, bug fixed, set date before setting attributes.

Thanks Razor for making these awesome programs, I did some tests as well and everything came back pretty much what Newbie posted. I tested lots of different extensions, unicode characters for the file name and file attributes (read-only and hidden). I used md5checker for the checksum and everything was identical to the input. One problem I found was if a file had the read-only attribute, it would always affect the date of the unpacked file no matter its extension; however that seems to be fixed now. Another problem is some of the dates of the restored files are changed (specifically 1 hour back, e.g. if the file was 10:00am to start with, it was 9:00am when unpacked). I did a test on 24 different exe files and 13 of them had their dates changed, it didn't matter if the file was hidden or not. Also I did a test on 3,485 files and only 491 of them got extracted, I did another test with the same files but with only 2,395 and only 320 of them got extracted. Out of the extracted files; some of the files had their dates changed like usual (1 hour back). If you want I could test the same files with the bug you just fixed if the dates still change, otherwise that's all the problems I found; please let me know if you need any screenshots!

Thanks guys, Will post another test after some fixes from the reports you provided.

As always, many thanksì Razor!
I tried adding some folders at random taken in System32 and is all ok but when I added the folder Roaming in input and started after unpack.exe in restore folder missing about 200 files approximately.
This only happened when I added the folder Roaming.

Update: Hey Razor, I decided to look deeper and figure out why ZArc was not extracting all the files. I found that there was three files that the system considered were 0 bytes in size and after removing them, ZArc successfully unpacked all the files. So it seems likes when ZArc encounters a file that is 0 bytes in size, it stops and doesn't compress files after it; e.g. file1: 1mb, file2: 500kb, file3: 0b, file4: 10mb (it will compress up to file2 and stop, so file3 and anything after it will not be in the archive). Also I decided to group the 3,485 files and compress by extension, it took a while but I think it was worth it because I found another problem. These extensions (.bin, .ini, .url, .ksh, .txt, .vdf, .xml) compressed successfully but got an error on decompression "EReadError: Stream read error". I thought to myself how can ZArc unpack all 3,485 files at once which include those extensions but not unpack the extensions individually. I'm not sure how I stumbled upon it but I started to look at the size of the archive, I noticed that ZArc could unpack an archive the size of 100kb but not 20kb. So I started to narrow the margin, I finally ended up with ZArc being able to unpack 64.2kb or higher but not 64kb or lower. I have no idea how I found that problem, but it was not the extensions that were the problem but rather the size of the archive. This applies to any extension, ZArc will not unpack if the size of the archive is 64kb or lower; otherwise you will get this error while trying to unpack "EReadError: Stream read error". Hopefully this helps Razor when trying to fix these problems! tell me if you need any additional information.

Thanks, will post another test using the info you have provided

can i ask a question, razor12911 what compression does corepack repack use until so low compression compare from others group?

Tried to fix some bugs and preparing for SFX (Self extractor) function for split and non-splitted archives.

The preparation of this means the first archive size differs from the rest, in this case, first split must be 195MB (Imaginary SFX is 5mb) and the rest is 200MB.

No compression is applied, testing store method which is the default method which comes with ZArc, otherwise things like srep, lzma are things which you can add by yourself because of copyright.

The other reason this is store compression is split archives are a headache (bugs everytime I use other compressors), I have to prepare something before everything works.

Progress: 65%

Things left to do:
Fix split archive bugs
Solid block feature
Add non stdin and/or stdout support
Make ZArc show progress
Command line version
GUI version

Nice work hermano...Tried about 20 different types of stuff.. Also, it shows error with a virus that I created :p (Virus= Size on Disk is 2 KB but when any program reads it, its 50+ GB).

Here's, one the All Okie screenshots:

Benchmark results between ZArc and Freearc

Ran test 5 times to compare duration between Freearc and ZArc again, before ZArc was ****** slow, so did a couple of changes and came back with these.

These tests are very much unreliable because they ran on HDD rather than RAMDisk, however, I tried to run a different test on RAMDisk and freearc kept failing over and over again, "Freearc has stopped working" error messages so HDD results are the only things I have.

Method is kept constant srep+lzma. First ran Freearc, meaning the first three tests are going to be bad, then I ran ZArc, 3 times as well, then 2 times for ZArc then ended with Freearc, just to keep results a bit fair.

Awesome work bro!!!!!

Another test, you can just test this on something that has many files. For example, Quantum Break.

It doesn't decompress just yet, have been busy, couldn't write code just yet for that.

thanks perfect for Quantum Break ! 600,000 files NO that's correct, so will test this & report back.