FreeArc features
 

Hello. I have a little question for this community.
What are the most requested features you would like to see in FreeArc?

DiskSpanning with Mask support.

we would like to see updates.

1. Pipes are slow (stdin - stdout)
Had work with Razor on some Zarc project some years ago pipes for arc were 25% slower at that time

2. finaly get updated to 64bit software. linux supported binaries.

3.Multi unpack (ability to unpack several arc files at once maybe with priorities)

4. Better grouping, masks only is able to detect 3 groups at a time.

5. ability to grab more than 100k files at once, (freearc after detecting 100k files as of now moves the rest to a different block)

Will edit if something comes to mind

Well ... more than seeing some additional features on a now obsolete and old compressor such as FA, my idea/hope has always been to see the finished and/or updated project, of the now also elderly FA'Next, where the he last update dates back to August 2016. But I think everyone's hopes have been lost on this too. At this point it is nice to settle for something new even and only for FA.:)

1, 2, 4: I'll see what I can do about it

3. Parallel multi-archive decompression usually can solved by external upper-level solutions. Parallel multi-block decompression is more promising

5. A large number of files in a solid block may affect performance

we can expect a boost if you can move arc into x64 architecture ??

there is room for improvement even though arc feels like a complete product, 10 years after its release it has not seen updates.

Perhaps an additional constant for FreeArc that specifies the number of CPU threads?

So, some tools allow you to specify thread count as a percentage (such as XTool)

However, some tools read from a static integer in arc.ini or cls.ini. This leaves us with the inability to tailor an installation to each user to use their full system (further in this post I have added an explanation of the LZMA archiver locked at 4 threads despite my system having 16).

I would like to suggest a new constant called {threads}, similar to how {compressor} and {option}. FreeArc can read this and substitute {threads} with however many CPU threads you have.

An existing example of this in action is the windows constant "%NUMBER_OF_PROCESSORS%" which if you echo it in command line will return the number of CPU threads in the system. I use this for when I use MTP or MParallel.

Further detailing this, I can use the open source LZMA archiver from the LZMA SDK as an example of how {threads} would work. Here is the normal unpack command for the LZMA archiver:

However, with our constant:

And because FreeArc handles the constant, it just replaces {threads} with however many threads you have and uses that as the unpack command passed to the EXE file.