FreeArc

[Intrinsic]

In English saying something is "functional" in the context used there is basically saying it's crap.
As an analogy i could say: Using a spoon to eat a steak will sort of work, but you are far better off using a nice sharp steak knife.
So it's saying Freearc is a spoon, and you are better off using something else.

[m^2]

Yeah, recently I'm saying the same about wikipedia with more and more often...too bad there's no good alternative.

[JangoFatXL]

most important sentence is

FreeArc archiver uses the same file extension but completely different file format.

as I see, some of you changed it to the version everyone can read now

[Intrinsic]

It should be: FreeArc - An up and coming but already functional archiving program that also uses the .arc extension

And you could even put very in front of functional too.

[Black_Fox]

FA in latest official stable release doesn't support compressing to any widely-used format. Face it, we like FA very much (and we do have why), but the usual noobs can't send the compressed files to other noobs (because they wouldn't know how to decompress them - they only can work with ZIP because there is support built-in into Windows).

Also, bear in mind that to comply with Wikipedia rules, the description must be neutral -> no hate, neither love has place there.

[JangoFatXL]

latest german translation

[Bulat Ziganshin]

new version:

• Fixed: processing directories and files inside directories was broken in latest alpha
• Fixed: when filetime is in 2038+ year, archive extraction was failing. now it sets filetime to 2038-01-19, last day of Unix epoch
• arc.groups: removed .bsa from compressed files list (these days it's game format, not BS Archiver
• Unix console version: disabled progress indicator in console title
• multi-threading support: switched to using LZMA2 code, now i finally can delete LZMA 4.x code from FreeArc sources
• Unix: by default allow to allocate up to 2gb of memory

[JangoFatXL]

# multi-threading support: switched to using LZMA2 code, now i finally can delete LZMA 4.x code from FreeArc sources

[JangoFatXL]

Impressive result on FF - Cinematic Mod 10.10 with -mex9 -md94m parameters

rep:1567452kb+exe+delta+tempfile+4x4:i0:lzma:44mb: normal:bt4:128, $obj => rep:1567452kb+delta+tempfile+4x4:i0:lzma:44mb:norm al:bt4:128, $text => dict:128mb:80%:l8192:m400:s100+lzp:160mb:92%:145:h 23:d1mb+4x4:b7mb: ppmd:13:200mb:c7mb, $wav => tta, $bmp => mm+grzip:8388096b:m1:l2048:h15:a
Memory for compression 1914mb, decompression 1664mb, cache 256kb

Compressed 25,390 files, 22,484,035,090 => 5,606,768,893 bytes. Ratio 24.9%
Directory has 2 chunks, 891,859 => 189,363 bytes. Ratio 21.2%
Compression time: cpu 9974.88 secs, real 3621.99 secs. Speed 6,208 kB/s
All OK

System Details:
-----------------
Windows7 x64
Athlon II 4x2,6GHz@4x3,5GHz
4GB memory

[JangoFatXL]

the following result is speaking for itself

Tested 25,390 files, 5,606,768,893 => 22,484,035,090 bytes. Ratio 24.9%
Directory 189,363 => 891,859 bytes. Ratio 21.2%
Testing time: cpu 496.43 secs, real 189.35 secs. Speed 118,741 kB/s

[Bulat Ziganshin]

it's just internal change, nothing new for users. shortly speaking, previously 4x4 and unarc used m/t classes (i.e. events/threads/mutexes support) from old lzma code, now from new one. but functionality of old and new code is equivalent, except that we may encounter new problems due to inacurate transition

[JangoFatXL]

it's just internal change

I know, but I like the idea of progress

No, seriously - I think you can see better behind the curtain than we and know the advatages of LZMA2 by comparison to LZMA.

[Bulat Ziganshin]

a few questions i got by email:

first of all thanks for FreeArc. I've been using it for almost two years
now and I'm amazed to see the progress you have been making.
I also want to thank you for srep. I love this little tool and I hope you
implement it into the gui-version of FreeArc soon, even if only
experimental. I know you don't plan on doing that, but please re-consider.
It would turn a lot of heads towards FreeArc and it would make the whole
process of using it much easier

Sorry for bothering you via email, but the forum you linked to on your
site (encode.dreamhosters.com) doesn't accept new registrations or I would
have opened a thread there.



I have several questions and also some bugreports. My main concern is your
dll and iss-script for InnoSetup. I recently tried to install an arc-file
that I created with the "-m=srep+delta+7z"-switch, but I only get the
following error:

"Decompression failed with error code -1
Archive test.arc is damaged
or not enough free space"

The arc-file works flawlessly with FreeArc so I assume some special
support for arc-wrapped third-party archives like 7z and lzma is needed to
make this work. Could you please implement that? That would be great.

While trying to get this to work I stumbled over a bug.
FreeArc_Example.exe worked great with a normal arc-file , but
FreeArc_Example-Ext.exe gave out the following error with the same file:

"Runtime Error (at 87:3390)

Invalid floating point operation"


Shouldn't be much of an issue since FreeArc_Example.exe works nicely, just
thought I'd let you know anyway.



I also ran into a few bugs with FreeArc:

- Whenever FreeArc runs out of space it closes the status window without
an error message. An error message would be highly appreciated. Even
better would be a dialog message asking the user whether he wants to
cancel or resume. WinRar does that and whenever I run out of space, I can
just resume the process without losing any work. This is a great feature
and FreeArc would certainly profit from it.



- If I use "Add to archive" in the integrated explorer menu and then press
cancel in the upcoming settings-window I receive 2 error windows (0.61
alpha):

"thread blocked indefinitely"

"gtk2hs_store_unref_node_impl: interrupted"

Doing the same in FreeArc directly works without problems though.



- Using the -m switch with arc.exe caused quite some trouble. Using the
following line that I found on one forum didn't work, even though it did
for that user who posted it:

-m=srep64+exe+delta+lzma:256mb:max:bt4:128:mc10000

Arc complained about srep64 being an unrecognized command. However, it was
present in the powerpack\bin-directory:

"Unsupported compression method or error in parameters: srep64"

Using just srep worked however. Is that a bug or did I do something wrong?



I'm also one of the x64 Windows users that never got the explorer
integration to work. I can now report that 0.61 alpha finally fixed that
problem


While I'm at it I want to bother you with a few requests

- Please include a proper documentation. This goes for FreeArc as well as
the command line version. For example I tried finding infos about chaining
commands with the -m switch, but couldn't find anything other than other
people's syntax on the forums you linked to with most of them not working
for me and I'm sure I'm not the only one Other issues for example are
FreeArc's space requirements during compression. Since it doesn't behave
like other programs in that regard it should be mentioned somewhere or
even shown in the progress windows so that people know how much space they
have to free up beforehand.

- Is there a way to set up the dictionary size manually in FreeArc? It
doesn't look like it. However, the changelog for 0.60 claims that bigger
dictionaries are supported now. How can I make use of that or does FreeArc
assign the size dynamically based on my system's ram size? My last info
was that FreeArc was limited to 96MB sized dictionaries, however the
compression settings seem to use the exact same values as in older
versions apart from the new ultra setting. Would I have to use that one to
make use of bigger dictionaries? (See how necessary a documentation is to
clarify what's up with the new and old features )

- Please make the error messages more understandable. This would help a
great deal to track down errors. For example if FreeArc runs out of ram it
just says "Error in (de)compressing tempfile". This could have a thousand
reasons. 7z is more straightforward by saying "couldn't allocate memory".
There it's immediately clear what the problem is.

- While FreeArc beats 7z by hundreds of MB in my recent compression tests
(compressing the 10GB game directory of Mass Effect), it performs worse
than 7z in combination with srep. You seem to recognize that yourself by
using 7z with srep in arc.ini instead of FreeArc itself. How come arc
performs so much worse in that case and do you already work on a way to
improve that?

- Is there a difference between srep and srep64 in regard of compression
efficiency?

and

Today I found something which might be two new bugs when using arc.exe.
One occured when I tried to use a 256MB dictionary with lzma:

-m:lzma:a1:256m:max:bt4:128:mc10000

arc.exe errored out saying that it couldn't allocate enough RAM:

"ERROR: can't allocate memory required for (de)compression in lzma:256m:normal:bt4:128:mc10000
Arc.exe: wclose: invalic argument (bad file descriptor)"

If I let it choose the dictionary size automatically it opted for 177MB. I have 4GB RAM in my comp (Win7 x64) and never had any problems using 256MB dictionaries, neither in 7z nor FreeArc. I usually have between 3300 and 3500MB free RAM available. When arc complained, I freed up even more, yet that didn't help. Could there be a 2GB address limit in the command line version?

Another bug happened in conjunction with 7z. When using the following syntax:

-m=7z:x9:d256m

7za would error out complaining about incompatible functions. This error message usually hints at a faulty syntax, but this only happened when I fed it a 7GB-file through arc. If I used something much smaller in the 50MB range it worked without any problems. May be this is a 7z-specific problem, may be arc doesn't handle the switches correctly. Whatever it is, it seems to be related to file sizes.

arc.exe uses 7za 9.07. Is there a way to update it to 9.10 manually?

[Bulat Ziganshin]

1. i also plan to slowly integrate srep. there are some improvements that i can do with separate executable before starting to do integration

2. "-m=srep+delta+7z" - you need to have arc.ini, srep and 7zip available for installer. it's described in FreeArc_Example-Ext.iss

3. "-m=srep64+exe+delta+lzma:256mb:max:bt4:128:mc10000" - use srep instead. or copy srep section in arc.ini into srep64 section. srep64.exe is 64-bit version that can compress files larger than 20gb, there is no any other differences

4. my prorities ATM is 7z.dll support and GUI usability. documentation and compression-related fetures are postponed, and most important part here is fixing shortages of -mex modes. i.e. all these things - srep, dispack and so on - get only small time slices

5. memory, dictionary, arc.ini and oher things are described in docfile

6. "You seem to recognize that yourself by
using 7z with srep in arc.ini instead of FreeArc itself." - what you mean? fa sucks compared to 7zip in two areas - it still have only bcj1 and lzma1 compressors. i will fix that but not soon. and of course you should compare srep+fa to srep+7z

7. "-m:lzma:a1:256m:max:bt4:128:mc10000" doesn't work, it should be "-m=...". largest dictionary you can use is 254 or 255 mb.

8. check which 7-zip version (32 or 64-bit) was called by freearc. 32-bit doesn't support dict>128m. when you compress small files, 7zip automatically reduces dictionary you've requested

9. "arc.exe uses 7za 9.07. Is there a way to update it to 9.10 manually" - i don't see much difference, but yes - you can update these two files yourself

9.

[Mexxi]

2. thanks! that did the trick somewhat. it made the installer extract the nested 7z from the arc-file, but i had hoped it would open the 7z within the arc and extract the files inside it like freearc does.

i actually checked out the iss-files, but unfortunately russian is not one of the languages that i speak

6. i actually did compare srep+fa with srep+7z. my test corpus was the installation directory of mass effect. using only fa and 7z made fa beat 7z by a whopping 210MB, but using srep made 7z beat fa by about 80MB (with same dictionary size). after some more optimizations of the 7z command line i was able to improve the compression by 25Mb, making 7z more efficient by 105MB in conjunction with srep.

7. the m: was a typo. i did use m=
i thought dictionaries over 1GB were supported since freearc 0.60?

8. this happened with the lzma-option which i thought was freearcs internal routine. 7z wasn't invoked at all.

9. true, there isn't much difference, but just out of curiosity. i replaced the 7z-file in the powerpack-directory, but arc still loaded the old 7z from somewhere. that's why i wondered.

thanks for answering my email and for putting up with all my silly questions so patiently

here's a small treat. i translated the dialogue from the iss-files into german:

ger.ArcBreak=Installation abgebrochen!
ger.ArcError=Dekompression fehlgeschlagen mit Fehlercode %1
ger.ArcBroken=Archiv <%1> ist besch?digt oder es steht nicht gen?gend Speicherplatz zur Verf?gung.
ger.ArcFail=Dekompression fehlgeschlagen!
ger.ArcTitle=Entpacke FreeArc-Archiv...
ger.StatusInfo=Dateien: %1%2, Fortschritt %3%%, Verbleibende Zeit %4
ger.ArcInfo=Archiv: %1 ?? %2, Gr??e %3 of %5, %4%% entpackt
ger.ArcFinish=Entpackte Archive: %1, Entpackte Dateien: %2 [%3]
ger.taskbar=%1%%, %2 verbleibend
ger.ending=fertigstellen
ger.hour=Stunden
ger.min=Minuten
ger.sec=Sekunden

I couldn't see "taskbar" and "ending" being used so my translation might be a little shaky there without context. If you need more translation work to be done, I'd be glad to help.

Edit: updated the translation

[Bulat Ziganshin]

7. dict up to 1gb supported only with ht4 matchfinder. hc4 - up to 511mb, bt4 - up to 255mb

8. "-m=7z:x9:d256m" will not work with 32-bit 7-zip

9. first 7-zip in PATH is invoked. try to run 7z from command prompt

ps: forget to say that the rest of your questions are known problems.

thanks for translation, i will add it. some strings used in one ISS example, some only in another, it's why you failed searching theirs usage

[Mexxi]

thanks for clearing all this up.

as for 2.) is there no way to extract the files in a 7z nested in an arc-file instead of 7z itself with your innoscript?

this is my arc-structure:

test.arc
> filecache.7z
>> $$arcdata$$.dll

I want to extract $$arcdata$$.dll directly, but only filecache.7z gets extracted. Is there any way around this? FreeArc opens $$arcdata$$.dll directly without even showing the 7z. I had hoped unarc.dll would do the same.


Btw, forgot to translate a word for the script:

ger.ArcBreak=Installation abgebrochen!

Also, in "ArcInfo" you seem to use an untranslated term: ??
Does that mean "file"?

[Bulat Ziganshin]

new version:

• GUI: running files directly from archive!!! file isn't runned if extraction operation was failed or canceled
• Settings: option "Unpack whole archive when running:"
• Settings: option "Show "Test archive" dialog"
• Extraction: option "Open output directory in Explorer"
• GUI: now it can delete directories from disk, recursively
• Fixed: file was remaining locked when FreeArc failed to open it as archive
• LZMA1: finally removed from sources

[JangoFatXL]

I guess

# Settings: option "Unpack whole archive when running:"

is only relevant in combination with

# GUI: running files directly from archive!!! file isn't runned if extraction operation was failed or canceled

if extracted file (executable) needs all archived files within archiv?

If it is like I suppose, I suggest to change "Unpack whole archive when running:" to "Unpack whole archive when running following file within archiv:" or something like that

It would be usefull to explain that option in tooltips, I will add some words about it...

[JangoFatXL]

tooltip suggestion:

--Interface settings
1467 Unpack whole archive when running:=FreeArc is able to run files within archivs. Nevertheless a lot of executable files are dependent from other files. If an executable file does not run properly, you can determine FreeArc to extract the whole archiv on certain, explicitly mentioned files, if you try to run it directly from archiv.
1469 Show "Test archive" dialog=If you activate that option, the test operation will be performed instantly without showing the mentioned dialog box

PS: if you abort this very option (0467 during a real operation), FreeArc forgets to delete temp files from specified temp files directory...

and last but not least: the latest german lang file (incl the new tooltips)

[Bulat Ziganshin]

1469 Show "Test archive" dialog=If you activate that option, the test operation will be performed instantly without showing the mentioned dialog box

except that it's oppposite how about

1469 Show "Test archive" dialog=Test operation will show dialog that allows to input passwords and other options of operation

[JangoFatXL]

eeehm - yes

[Bulat Ziganshin]

new version:

• .gz/.bz2 support
• GUI: don't show Detach button when Add/Extract dialog opens from Explorer context menu
• GUI: fixed execution of Detach button with directories
• Proper error message on attempt to modify 7z.dll-supported archive

[Intrinsic]

Or how about:

1469 Show "Test archive" dialog=This will test the integrity of the currently opened/selected archive for any errors, and if necessary ask you to enter the archive's password to complete the operation.

Seems a few of the English sentences are wrong, but some of the ones i noticed aren't in the arc.english.txt file for me to edit?

IE:
"Watch for new version via Internet"

to

"Automatically check for updates via the Internet"
Could also be worded as "Automatically check for updates" as the Internet is the only way in which it can do that anyway.

and

"You should restart FreeArc in order for a language settings to take effct. Passwords need to be entered again after restart."

to

"You will need to restart FreeArc for any change in the language settings to take effect. Any passwords previously entered will need to be re-entered after the restart."

[Bulat Ziganshin]

updated (i've missed several files)

[JangoFatXL]

corrected the mentioned tooltip

[Skymmer]

Noticed strange thing with compression via context menu. It appears quite randomly. When operation is in progress and you press 'Cancel' button then the following messages are given:
http://skymmer.narod.ru/images/shots/023.png
http://skymmer.narod.ru/images/shots/024.png
http://skymmer.narod.ru/images/shots/028.png
Also, $$temparc$$1.tmp file is not deleted sometimes in this case.

Version: 19 Feb 2010
OS: XP Pro SP3 (32-bit)

[Bulat Ziganshin]

... and you press 'Cancel'

Cancel processing for any operation is still bad, bad, bad...

[jethro]

Does 'Make exe' SFX work for archives >4GB? Because I'm getting 'archive.exe is not a valid Win32 application' error.
I made this archive myself (7.15GB) and when opened in GUI everything shows fine. However in explorer there's no freearc icon (only default exe icon) and it cannot be run. First I thought that maybe I forgot to select 'make exe' so its .arc file with exe extension so I opened it again as .arc in GUI, selected 'convert to SFX', it processed fine, deleted old file and created new .exe but still same error

[Bulat Ziganshin]

windows limits exe files to 500 mb or so (probably it depends on largest memblock available since windows maps entire file to memory before executing it). make archive.arc and put freearc.sfx renamed to archive.exe to same dir. xxx.exe will extract xxx.arc