ZArc (Alternative of Freearc)
 

Seems like Freearc 0.70 ain't coming.

Working on this.

Progress: 5%

Pipes work great, all i need to do is convince Zee to put some compression power on it.

Default will be the Store Method ...

Progress 10%

Managed to do stdin stdout (pipes) for 2 or more exe, it was awfully difficult but only left with optimising the code to break that 12 seconds on top of that, I'm not even checking file hash or anything like that, so yea, that gap is bad.

Anyways, here is a program that needs testing, haven't slept for almost 2 days working on this and other projects.

What needs testing here is simple, just use the method brute+srep+lzma and compare the file sizes of this and the ones from Freearc, if you're lazy to set up brute+srep+lzma then just run this on certain files and report back errors.

BTW, Splitting feature can be done but tricky. but once I'm able to split, then putting the file back will be easy. There will be no temps to merge the file back like I did with UltraARC. Gonna be difficult but hopefully not that difficult.

How to test?
Just put data.tar near ZArc.exe and run the exe, it will work and show summary, output will be placed in the same directory.

How to test on files ? I mean directory of files etc. What should I do :rolleyes:

Mad Max
game24.bin - 812mb

data.unp - 140mb (449s)

GTA V x64b.rpf

Brute: 143 MB > 308 MB
Srep: 308 MB > 204 MB
Lzma: 204 MB > 115 MB

Took: 187 seconds
Done

why you are skipping delta+dispack?

I didn't skip it, it's optional to users.

Hey! Look is Bulat.
Hi Bulat!

Is you have any plans to update your FreeArc Project?

You were already answered, check encode.

Test 2 uploaded

Added splitting feature test, just add files in input folder and run exe

You are always really creative and I wish you always lasting success Razor12911

work nice. i can't see the signature or header in the file.
this is correct?

What to test?

Well I added 2 test this time in 1

restoration test:

All you do is place a file, "INPUT.dat" then run ZArc, compression will start then afterwards decompression, you'll have 2 new files, OUTPUT.dat is the compressed file and RESTORED.dat is the unpacked file, to test if file was restored properly, just compare CRC for INPUT.dat and RESTORED.dat, if it the same then I'm on the right track.

splitting test:

All you do here is add files in input directory, if possible just use the same input you used in restoration test so that you can check if the size of the content in output direct is roughly the same, CRC must be the same because headers aren't really included in the splitting process if it isn't then shame, will have to look at the custom stream sources and do modifications.

What's remaining?

* No stdin and/or stdout compressor support (Currently busy with this)
* Add header information, date of files, CRC, file names, file sizes etc
* Make ZArc use ZArc.ini
* Command line version, drag and drop etc
* Restoration of splitted archives (Already have a strategy of how to complete this task)
* Add Groups/Masks
* Make GUI

@ChronoCross
Yep, correct. I haven't added headers yet.

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.

What's the progress of zarc?
Any updates

am currently busy with solid blocks, should have been done with this a long time ago, was busy with personal matters, not really personal matter per se, am so lazy to code. Already added disk spanning with disk request dialogs. Right now, am still lazy, sitting on my arse watching the grand tour.

Watching grand tour hmm drink redbull you should get wings ;)

A couple of screenshots.

Test 6:40 AM 1/27/2017

Razor give us more information on the topics and options relating to the use....

data input : 236mb

Line : ZArc a -r -fv36m -v100m -msrep+lzma "C:\DataTest" -o data.arc

(EAggregateException: One or more errors occurred) ?????

In Out :

data.arc.001 .... 36.864KB

data.arc.002 .... 102.400KB

data.arc.003 .... 12.804KB

What criteria get this division of archives, input data division and then compress, or creating the temporary file input, compression and division into parts as option configuration "-fv36m -v100m".....I think it was logical the second, but the result approaching more to the first.

Program is still in the shed being worked on plus there really wouldn't be a point in disclosing options because decompression doesn't work yet.

Have seen this error before, caused by... don't know what causes it really but will solve problem.

Well it's just the same as Freearc except when writing to final archive, ZArc choses to split data, meaning when decompressing, there are no temps created to combine archive into one part, it will decompress just like 7-Zip and other programs that have disk spanning, it will just request for more disks when they are missing. The idea of UltraARC is not what is used here. And input is not divided either.

My idea is a personal project that I never published is another, Arc is not able to divide an archive, the basic concept that we all know, or nearly so, is to divide the input folder and then compress the parties as archive.
Arc during compression followed by a method therefore with different compressors, creates a temporary file "$$arcdatafile$$.tmp" which is the input data to be compressed, the second step is created a second temporary file "$$arcpackedfile$$.tmp" that creates the archive size, and it is this second file that should be divided into equal parts and in exact size, previously set, in order to create a set of split archives.

Win 10 Pro x64
http://uupload.ir/files/cs53_2017-01-27_172418.jpg

Well splitting input doesn't work very well with final ratio, which is why I ditched that idea.