View Issue Details

IDProjectCategoryView StatusLast Update
0003298PluginsArclitepublic2017-01-10 13:58
ReporterHermanSemm Assigned To2useven10  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Platformx86OSWindowsOS Version10
Summary0003298: Difference 7z archive size result between compression level ultra - normal - max
DescriptionHi Far team..

I might be experienced bug when working with Far 30 build 4774 when add/creating archive, as below:
1.The archive.7z size result in win10 x86: ultra > normal > max
2.The archive.7z size result in win7 x86: normal > ultra = max

Note: > means size Bigger than, = means size Equal to

I think it's also depends on various kind of processor and windows with x86 or x64, also RAMS.
But you should fix this problem anyway.

I hope you could fix this problem soon and please reply to herman.semm@gmail.com...

Best Regards,
Herman Semm
TagsNo tags attached.

Relationships

parent of 0003330 closed Arclite problem still there but you didn' concern 
parent of 0003331 closed Sample of .7z result According to Report ID=0003330 
has duplicate 0003308 closed2useven10 7z archives sizes produced by Far Manager 3 at level ultra is always bigger than level max and normal 

Activities

shmuel

2016-09-11 06:43

developer   bugnote:0014754

Hi Herman,

1. The Project and Category you selected are incorrect. The correct values are:
Project=Plugins, Category=Arclite. (Only administrators can repair that).

2. There is no need to manually send replies to your email, it is done automatically.

2useven10

2016-09-11 07:56

developer   bugnote:0014755

Last edited: 2016-09-11 07:57

what is number of cpu cores on win10/win7 system?

2useven10

2016-09-11 08:29

developer   bugnote:0014757

also you can check 7z.exe results with same parameters.
if far3/arclite sizes == 7z sizes -- you should ask 7z author about that.

HermanSemm

2016-10-18 05:27

reporter   bugnote:0014928

According to Report ID=0003330 (Closed)
Here I send you sample of .7z archives created by Far & 7-Zip File Manager in "Please Extract This File 1st.7z", please see differences of sizes result carefully that:
"Far 3 Arclite: Ultra .7z size is always bigger than Maximum and Normal / same result even when compressing bigger sizes of other kind of files"

All compressed with same settings using 7z version 16.04 in Solid archive with:
-Compression Level= Ultra, Maximum and Normal
-Compression Method= LZMA2
-Command line switch for Far 1.75 7z Multiarc= -mx=9 -ms=4g (LZMA2 Solid Ultra), -mx=7 -ms=4g (LZMA2 Solid Maximum) and -mx=5 -ms=4g (LZMA2 Solid Normal)

1.On Windows 10 x86 with Core 2 duo 2.00GHz (Same result on Windows 10 x64 with Quad Core 3.00GHz), files are:
-Far 1.75 (build 2634)
Ultra: F1W10C2u.7z
Maximum: F1W10C2m.7z
Normal: F1W10C2n.7z

-Far 2.0 (build 1807) with 7z.dll version 16.04
Ultra: F2W10C2u.7z
Maximum: F2W10C2m.7z
Normal: F2W10C2n.7z

-Far 3.0 (build 4826)
Ultra: F3W10C2u.7z
Maximum: F3W10C2m.7z
Normal: F3W10C2n.7z

-7-Zip File Manager Version 16.04
Ultra: 7fmW10C2u.7z
Maximum: 7fmW10C2m.7z
Normal: 7fmW10C2n.7z

2.On Windows 7 x86 with Pentium 4 1.8GHz, files are:
-Far 1.75 (build 2634), same result as 7-Zip File Manager Version 16.04
Ultra: F1W7P4u.7z
Maximum: F1W7P4m.7z
Normal: F1W7P4n.7z

-Far 3.0 (build 4826), same result as Far 2.0 (build 1807) with 7z.dll version 16.04
Ultra: F3W7P4u.7z
Maximum: F3W7P4m.7z
Normal: F3W7P4n.7z

I hope you would see this problem more clear and could fix this soon (I hope you could also fix the Far 2 Arclite)..

Regards,
Herman Semm

HermanSemm

2016-10-18 05:29

reporter  

DrKnS

2016-10-18 05:32

administrator   bugnote:0014929

Ok, I can confirm that with that particular data (actually, ncmain.exe is enough to reproduce it) "ultra" produces bigger file than "maximum" and this doesn't happen with 7-zip file manager using the same 7z.dll.


We will investigate this.
Please, do not create any more duplicate issues.

2useven10

2016-10-18 11:30

developer   bugnote:0014930

Last edited: 2016-10-19 05:49

              Size  arclite-max  7z-max  arclite-ultra  7z-ultra
NC.EXE        2912         1944    1944           2009      2000
NCMAIN.EXE  212416        96087   96087          96712     96048
corrected...

2useven10

2016-10-18 11:34

developer   bugnote:0014931

NCMAIN is probably arclite problem.

HermanSemm

2016-10-19 02:44

reporter   bugnote:0014935

Last edited: 2016-10-19 05:52

.7z results on my Windows 10 x86 with Core 2 Duo and on my Windows 10 x64 with Quad Core are=

              Size  arclite-max  7z-max  arclite-ultra  7z-ultra
NC.EXE        2912         1944    1944           2009      2000
NCMAIN.EXE  212416        96087   96087          96712     96048

I've been experienced that there're no problem when comparing Arclite vs. 7z at compression level Maximum and Normal etc. the size always equal.

The Problem only happens at compression level Ultra as above.

Please do more compressing test with your other bigger size of file(s) then you'll see the problem more clearly..


Note: Sorry for adding and deleting notes until 3 times, because after Add Note the data being squeezed as above..

2useven10

2016-10-19 06:04

developer   bugnote:0014938

You are right. NC.exe -- 2009/2000.
The problem is cleared enough.
But the reason unfortunately is not so evident.

HermanSemm

2016-10-20 01:07

reporter   bugnote:0014940

Just focus to Arclite, the main problem is in Arclite, because when compressing anyfile(s) at compression level Ultra it always produce bigger archive size than level Maximum or Normal.
If the problem still there means it useless there's Level Ultra in Arclite.
You're the developer, so I'm sure you'll find the way to fix it.
This problem happened since Far Manager 2 Arclite, please fix it either...

2useven10

2016-12-27 17:45

developer   bugnote:0015107

build 244

Issue History

Date Modified Username Field Change
2016-09-11 05:44 HermanSemm New Issue
2016-09-11 06:43 shmuel Note Added: 0014754
2016-09-11 07:54 2useven10 Category Command Line/Execute => _Common
2016-09-11 07:54 2useven10 Project Known Error => Plugins
2016-09-11 07:55 2useven10 Category _Common => Arclite
2016-09-11 07:56 2useven10 Note Added: 0014755
2016-09-11 07:57 2useven10 Note Edited: 0014755
2016-09-11 08:29 2useven10 Note Added: 0014757
2016-09-21 09:46 shmuel Relationship added has duplicate 0003308
2016-10-17 12:13 2useven10 Status new => closed
2016-10-17 12:13 2useven10 Assigned To => 2useven10
2016-10-17 12:13 2useven10 Resolution open => no change required
2016-10-17 14:14 2useven10 Relationship added parent of 0003330
2016-10-18 05:01 DrKnS Assigned To 2useven10 =>
2016-10-18 05:01 DrKnS Status closed => new
2016-10-18 05:02 DrKnS Relationship added parent of 0003331
2016-10-18 05:27 HermanSemm Note Added: 0014928
2016-10-18 05:29 HermanSemm File Added: Please Extract This File 1st.7z
2016-10-18 05:32 DrKnS Note Added: 0014929
2016-10-18 11:30 2useven10 Note Added: 0014930
2016-10-18 11:30 2useven10 Note Edited: 0014930
2016-10-18 11:32 2useven10 Note Edited: 0014930
2016-10-18 11:34 2useven10 Note Added: 0014931
2016-10-19 02:44 HermanSemm Note Added: 0014935
2016-10-19 02:49 HermanSemm Note Edited: 0014935
2016-10-19 03:11 HermanSemm Note Edited: 0014935
2016-10-19 05:48 2useven10 Note Edited: 0014930
2016-10-19 05:49 2useven10 Note Edited: 0014930
2016-10-19 05:49 2useven10 Note Edited: 0014930
2016-10-19 05:52 2useven10 Note Edited: 0014935
2016-10-19 06:04 2useven10 Note Added: 0014938
2016-10-19 07:29 DrKnS Priority immediate => normal
2016-10-19 07:29 DrKnS Severity feature => minor
2016-10-19 07:29 DrKnS Resolution no change required => open
2016-10-20 01:07 HermanSemm Note Added: 0014940
2016-12-27 17:36 2useven10 Assigned To => 2useven10
2016-12-27 17:36 2useven10 Status new => assigned
2016-12-27 17:45 2useven10 Note Added: 0015107
2016-12-27 17:45 2useven10 Status assigned => feedback
2017-01-10 13:58 2useven10 Status feedback => closed
2017-01-10 13:58 2useven10 Resolution open => fixed