There is a server based on Centos 6 or 7, noticed such a feature.

Sometimes you have to upload a zip file to the server and unpack it on the server.

There is no regular support for zip, you must first install sudo yum install unzip , after which you can unzip ( unzip -d /where_to_unizp/ filename_to_unzip.zip ) or midnight commander from the command line.

And that's what's strange. For some reason, mc unpacks incredibly long. From the command line - well, a couple of seconds, and in mc - the same file can show exorbitant numbers:

 β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€ ВсСго: 196K/721M ──────────────────── β”‚ ΠžΠ±Ρ€Π°Π±ΠΎΡ‚Π°Π½ΠΎ Ρ„Π°ΠΉΠ»ΠΎΠ²: 83/50564 β”‚ β”‚ ВрСмя: 0:03:08 ETA 197:06:15 (1,04 ΠΊΠ±/с) β”‚

Why is it and can it somehow speed up?

I have an assumption that this has nothing to do with the keys for unpacking, but with the fact that it is first unpacked somewhere through some intermediate buffers.

  • No need to use a product called mc, never. - 0andriy
  • @ 0andriy, was altenativa. in the total commander was copying direct access, accelerated 5 times) - eri
  • 2
    The problem is that ms unpacks the archives in two stages - at the first stage it makes a list of files, and at the second - for each individual file, the decompressor calls for each file separately. For what it is done - I do not know. I suspect - in case the archives are in the archives. This problem exists when unpacking archives of all types, and not only zipovanyh. So I always unpack large archives either from the command line or with a regular unpacker from the menu. - Sergey
  • @Sergey your comment is quite suitable for the role of one of the answers. - AK ♦
  • 2
    not only archives, any vfs in mc works very slowly - eri

1 answer 1

Set the parameter in the inc file mc to true, it will be a bit faster. Default:

 preallocate_space=false