Открыть список
Как стать автором
Обновить

Комментарии 296

Меня и gzip устраивает, а если нужно что-то сильней сжать, то zstd

gzip не архиватор, а утилита для сжатия и распаковки, как и zstd. Архиватором в случае их использования обычно является tar.
7-zip же всё в одном, в этом от аналогичен arj, rar, ace и прочим утилитам, в основном популярным под Windows.

> gzip не архиватор, а утилита для сжатия и распаковки, как и zstd. Архиватором в случае их использования обычно является tar.

Как много дистрибутивов Linux вы знаете в составе которых нет tar?
А при чём тут это? Tar примитивен. У него нет оглавления. Чтобы просто посмотреть, что в нём лежит, надо тупо распаковывать всё.

Может быть потому, что tar создавали для записи данных на магнитную ленту, и его задача не архивировать, а обеспечивать непрерывный поток данных для записи, поэтому он и примитивен. Он не является архиватором, в привычном нам понимании, потому как ни чего не сжимает.
А вот gzip как раз сжатие выполняет, и поэтому часто работает вместе с tar.

Так о том и речь, что какого фига, спустя 40 лет, tar до сих пор является основой большинства способов архивации и множества пакетов, если он для этой задачи не предназначен, и плохо справляется. И нельзя сказать, чтобы альтернатив не было. Но все пользуются tar потому, что все пользуются tar, и все будут пользоваться tar потому, что все будут пользоваться tar. Железобетонный аргумент.
нет, речь не о том. tar+gzip самодостаточны, потому что работают с потоками, что обеспечивает отдельный отличный функционал. Может быть сейчас не все используют магнитную ленту, но в линуксе есть и другие устройства, с которыми можно работать напрямую и сразу редирекить что-то в tar/gzip
Для сжатия образа диска tar не нужен. Папку с файлами на вход отправить через шелл нельзя, поправьте, если не прав. Получается, в двух самых бытовых случаях возможность, как вы сказали, «работы с потоками» не нужна. А в нишевых случаях всегда можно продолжать им пользоваться, никто ж не призывает выкинуть tar из дистрибутивов. Я лишь говорю — нужно перестать использовать tar чтобы сжимать им папки с файлами. Настало уже время перейти на что-то более умное.
Архивы tar чаще распаковывают чем запаковывают.
Потокового функционала мне более чем достаточно, например я пользуюсь — распаковка архива одновременно со скачиванием его по ссылке, без сохранения промежуточного.
curl https://a.b/c.tar.xz | tar -xJ


каждый инструмент нужно использовать там где он подходящий, если надо я и 7z использую, и образ диска с файловой системой, поддерживающей сжатие, и т.п.
curl https://a.b/c.tar.xz | tar -xJ

Эх, вспомнил как я, будучи совсем юным студиозусом, распаковывая огромный по тем временам архив через WinRar, как-то раз раз дико удивился двум вещам:

  • А чего это все время вылазит ошибка распаковки? Архив то не битый точно
  • И куда девается всё место на диске С? Вроде же на D распаковываю, я ж вам не ламер какой, честно — пречестно ))

Но, к слову, тогда быстро пришло некое осознание того, что «не все так просто в датском королевстве», я начал это дело копать, ну и в итоге это стало частью одного из кирпичиков знаний
Ну да, 7zip распаковывает в Temp, а потом почти столько же копирует на другой диск, если это делать перетаскиванием. Если через интерфейс указать путь, то распаковка идёт сразу в нужный каталог.
Папку с файлами на вход отправить через шелл нельзя, поправьте, если не прав.

Это в каком смысле?
Если имеется ввиду графическая среда, то папка с файлами нормально перетаскивается в архив tar (со сжатием сверху или без) в Ark (в KDE).
Возможно, что в других графических средах (Gnome, Mate, Fly) оно тоже есть.
Если имеется ввиду какой-нибудь bash, то нормально принимает на вход папку и всю ее загоняет в архив.
В mc оно тоже неплохо добавляет папки в tar.
Если имеется ввиду конвейер, то какой архиватор может?


Я лишь говорю — нужно перестать использовать tar чтобы сжимать им папки с файлами. Настало уже время перейти на что-то более умное.

Оно, конечно, давно p7zip.
Но раз на два не приходится. tar и gzip в любом дистрибутиве линукса предустановлены (по крайней мере пока без него не видел), а другие архиваторы-разархиваторы (даже unzip) могут отсутствовать (встречал такие случаи, особенно на серверах). Это как zip во всех остальных случаях — средство гарантированного понимания.

Это в смысле что мы говорили конкретно о bash pipe. Ими и нельзя передать папку на вход tar. Поэтому способность tar получать данные на вход через pipe не имеет практической пользы при запаковке папки с файлами.
У p7zip тоже свои проблемы есть. Софт почти не развивается. Полгода назад в Арче самая свежая версия была от 2016 года. Как сейчас — не знаю. Алгоритм сжатия юзером не заменяется, а алгоритмов новых уже придумали и ещё придумают.
О, свежачок, хоть zstd добавили — приятно.
Поэтому способность tar получать данные на вход через pipe не имеет практической пользы при запаковке папки с файлами.

Ну очень даже имеет смысл, например в случае, когда вы хотите с удаленной системы в которой файловая система ридонли, взять какой-нибудь каталог и скачать его архивом. Берешь каталог, через find, пихаешь его в tar/gzip, кидаешь прямо в ssh а с той стороны прямо из ssh распаковываешь. И нигде не нужно создавать сам файл архива — ни там ни тут.
Вы конечно скажете про rsync/scp, но это уже каждый файл отдельно.
Можно пример команды на отправку, а то я честно не понял, о чём речь. Мой стиль баш-фу не чист: использую parallel k месту и не к месту…

Простейший вариант:


tar czf - <files> | ssh user@host "cd /wherever && tar xvzf -"

Упаковываем файлы, но не пишем архив на диск, а сразу шлём его по ssh туннелю, где этот архив на лету распаковываем в папку. Ни одной промежуточной записи не требуется.

Так и я могу. Пусть покажут, что сказали: файлы на запаковку в tar подаются через pipe.
Ну так сделай тоже самое через zip?

Ну или вот простой пример:
Ну например банально:

mongodump blablabla --archive | tar
Для галочки.
За все реализации не скажу, но GNU tar вполне понимает список файлов в stdin через -T
find . | tar -cvf /dev/null -T -

Для сжатия образа диска tar не нужен.

Так так и не сжимает, он «каталогизирует»

Папку с файлами на вход отправить через шелл нельзя, поправьте, если не прав.

Смотря что вы имеете ввиду. Список с файлами легко, через тот же find, но ведь папка — не является устройством и следовательно потоком.

Я лишь говорю — нужно перестать использовать tar чтобы сжимать им папки с файлами.

так таром и не сжимают, сжимают gzip, который с tar в хорошей синергии именно из-за умения работать с потоками.

А для просто сжатия — есть обычный zip/bzip/ну и наконец 7zip. Просто перейти на что-то более умное можно будет тогда, когда оно доступно в каждом дистрибутиве из-коробки. RAR в этом случае не подходит — платный (а зря), а 7zip бесплатный, и я новости радуюсь.
«Я лишь говорю — нужно перестать использовать tar чтобы сжимать им папки с файлами. Настало уже время перейти на что-то более умное.» — при выборе ПО первым критерием (после очевидных, что ПО должно работать и иметь документацию хотя бы на минимальном уровне) беру «ПО не должно быть умным». Умным должен быть пользователь.

Тар-ом пользуются для архивации, потому что он как раз хорошо подходит для этой задачи, во всяком случае, не страдает таким идиотизмом (см ниже), как как при распаковке из рам-диска на рам-диск сохранять промежуточные файлы на системном жёстком. Да и производительность при поиске файла тоже неплохая, так как он перескакивает от заголовка к заголовка, считывая с диска минимум информации. А вот со сжимающими утилитами проблема есть. Здесь много чего следует усовершенствовать.

А что касается сжатия… следовало бы сравнивать с возможностями сжатия на уровне ФС. Это удобнее, так как не надо ничего запаковывать/распаковывать, это может быть быстрее за счёт использования инструментов уровня ядра, и это может дать большее сжатие за счёт большего числа файлов. Надо проводить эксперименты.
Тар

диск сохранять промежуточные файлы на системном жёстком

Эм, это от формата зависит примерно никак.
и это может дать большее сжатие за счёт большего числа файлов

Эм, все известные мне файловые системы со сжатием сжимают отдельные файлы поблочно, и тут никак не поможет то, что файлов много, скорее даже помешает.
А еще через tar очень удобно размещать файлы проектов для создания порта из linux в windows.

Например я не помню команду создания символических ссылок в windows. А в проекте — они используются. Просто делаю tar в linux, распаковываю его раром или семьзипом в виндовс — и имею каталог проекта с рабочими символинками, которые создали программы а не я. Если же копировать из линукса в винду средствами ФМ то не получается создать символинки, т.к. нужно обладать правами администратора. Может и можно как-то создать коннект между двумя операционками с админ-правами на винде, но мне проще вот через тар, чем что-то гуглить ради того что потребуется несколько раз в год :)
Пользуются потому что удобно.

Например я использую tar для создания резервных копий дерева исходников. никакие гиты не заменят этот способ, т.к. гит удобен когда кладёшь в него что-то завершенное (фичу, фиксобаг, готовый таск). А на пути к этим этапам очень удобно сохранять рабочиепромежуточные версии (чтобы не убить, и не откатываться потом до последней рабочей версии из гита) — используя tar. Он внушат уверенность что после восстановления из tar — все меданные создания/изменения файлов будут оригинальными. Если же делать эти манипуляции через обычные средства (скопировать — вставить), то как минимум дата создания файла поплывёт. А эти данные между прочим помогают ориентироваться, не плохо помогают. И нет нужнды для таких операций, при дешевом дисковом пространстве — тратить вместо 20 секунд помещения в tar — например 80 на сжатие каким-то алгоритмом.

И даже если не брать профессиональную сферу, то именно в сохранении метаданных нахожу удобство tar, например резервное копирование семейных фотографий (где кроме jpg, еще и raw, не сжатое mov).

Никакие облака для этого не годятся, так же и тратить время и киловатчасы на сжатие терабайтных директорий — ну такое себе.

Просто подключаешь диск, и создаёшь архив tar на диск для резервных копий. И если основной диск умрет — потом можно восстановить и метаданные останутся как были, фотографии снятые в 2000х, так и будут иметь «время создания», «время изменения» — и вот это очень ценно. Когда прожил много лет, и накопил хороший личный-медиа-архив — вот эти вот «время создания 2002.12.31» — не менее ценно чем само содержимое фотографии.

И да, концептуально tar именно архиватор, и *.tar — это файлы архивов. К архивам в общем нет требования чтобы они были сжатыми. В тех же zip,rar можно паковать без сжатия. Более того в rar (единственном из всех) есть возможность создать архив с информацией для восстановления, при выключенном сжатии — архив получится больше чем размер оригинальных данных.

Очень полезная функция, например если потерялась одна/несколько из дискет — то при хорошем процентном (определяется в настройках) соотношении информации для восстановления — все данные восстановятся, как будто бы и не терялось ничего. В современном мире чуть менее но актуально, пример — умирающий носитель информации.

не нужно сгущать краски. связка tar+gzip давно не является стандартом, как вы давно уже не жмете в arj или zip. rpm или deb жмут в lzma, например, на сколько я знаю. другими дистрибутивами пользуюсь редко, поэтому ни чего не могу про их пакетные менеджеры сказать.
если под nix системами до сих пор этот тандем и используют для обмена файлами, то исключительно потому, что это работает на подавляющем большинстве систем, не зависимо от опций установки ОС. пока это работает, этим пользуются, особенно, когда требуется раздать файл +100500 тысяч человек. перестанет работать — перестанут пользоваться. ни кто не заставляет вас отказываться от 7-zip, если вы точно знаете, что ваш коллега/знакомый/друг точно сможет этот архив прочесть.

Функция сжатия в архиваторе опциональна, т.к. основная функция архиватора — собрать кучу файлов в один. tar и cpio это умеют и они оба считаются архиваторами.
Другие архиваторы (вроде 7-zip или старого доброго zip) пошли дальше и в них сжатие (и даже шифрование) является стандартной функцией.

Как ни странно — такого примитива более чем достаточно для очень большого круга задач. Например, когда из репозитория скачивается программный пакет для установки в систему — никому и в голову не приходит отдельно просматривать оглавление: пакет после скачивания весь разворачивается в нужное место.

Вот чего действительно не хватает в мире архиваторов — так это программы, позволяющей использовать архив (возможно, с компрессией) вместо (в роли) папки с файлами. Причём не монтировать его (это доступно только админу), а предоставлять доступ на уровне приложения, через библиотеку. Т.е. чтобы данные заливались на сервер и хранились там в компактном виде.
Разумеется, предполагается, что данные меняются крайне редко, а вот читаются довольно часто.
Вот чего действительно не хватает в мире архиваторов — так это программы, позволяющей использовать архив (возможно, с компрессией) вместо (в роли) папки с файлами.

Вы только сейчас проснулись? Webpack, initramfs, squash, cpio, iso-образов вам мало?
Причём не монтировать его (это доступно только админу)

С чего бы?
suid, polkitd, fuse. Куча вариантов.


Ну и в виде программного интерфейса это лет 20 уже существует
https://docs.oracle.com/javase/7/docs/technotes/guides/io/fsp/zipfilesystemprovider.html

предоставлять доступ на уровне приложения, через библиотеку

physfs? В любом случае, все технологии, перечисленные в ответах к этому комментарию, существуют не один десяток лет.
Вот чего действительно не хватает в мире архиваторов — так это программы, позволяющей использовать архив (возможно, с компрессией) вместо (в роли) папки с файлами. Причём не монтировать его (это доступно только админу), а предоставлять доступ на уровне приложения, через библиотеку.

Ну это не совсем так. Программа ZipFolders делала это еще в начале 2000х
Вспомнилось
image

tar --help

Вот тут могло быть и -H
-H, -h вместо --help могут привести к неприятным последствиям
arj, ace

ha, да вы археолог!

pkunzip.zip, от создателей ha.ha

Какие-то фидошные шутки в комментах. Борода которых раз в десять длиннее моей. ;-)

Ну я ace довольно активно пользовался в своё время. До выхода какой-то из версии rar (2.90, кажется) он мне очень нравился.
arj тоже удалось застать.

WinAce был особенно хорош, т.к. умел хорошо сжимать файлы и пиликать спикером, когда нужно было заменить дискетку при создании многотомного архива.

Я бы к археологии скорее ain отнёс — не многие его застали, но жал он круче любого архиватора той эпохи, и был быстрым.

А если вам прислали архив в 7zip?

Нужно понимать, что 7zip стал стандартом дефакто для подавляющего большинства windows-пользователей, и он умеет не только в zip, но и в 7z, который на линуксе распаковать нечем.

И это очень хорошо, что теперь 7zip официально доступен на обеих платформах.

Вдобавок, научитесь не путать потоковое сжатие gzip и архиватор.

На Linux нечем распаковать 7z? Вот так новости. p7zip (7z команда — это он) уже не первый год вроде как есть, используемый многими gui надстройками для архивирования и разархивирования без проблем. Но и официальная поддержка это, конечно, неплохо.

Я вот недавно столкнулся с тем, что на rhel7 сходу zip не установлен, и его нужно устанавливать, что вызывает проблемы, если нет прямого доступа в продакшен.
И это еще хорошо, что он в официальном репозитории остался.

Это не доказывает того, что в линуксе не было поддержки 7z ещё как минимум несколько лет назад. Иначе, например, я не мог бы установить виндовс-игры под вайном, ибо 7z-архивы. Как же я и другие ставили, если нечем было открыть?

А точно мой комментарий был прочитан до конца?
в современном мире в таких холиварных вопросах всегда упускается одна очень важная деталь. Многопоточность!
gzip — однопоточный и всегда будет проигрывать архиватору кторый умеет в многопоточность в разы.

вопрос к Tyooo: официальный 7-zip на линуксе в многопоточность умеет?
Есть мультитредовые версии разных компрессоров, pigz например для gzip, производительность у разных может кратно отличаться в зависимости от настроек
суть однопоточности в gzip, потому что он на вход может принимать не файл, а именно поток. И компрессировать именно его, а не целый файл. В результате, пока другие архиваторы ждут целый 10-терабайтный файл, gzip уже сжимает и отправляет сжатое дальше.
Ну и плюс pigz
Ну как бы да, но с другой стороны, в stdin он себе обычно как раз файл и получает, и вот эта unix-style архитектура оказывает ему медвежью услугу. Другие архиваторы с произвольным доступом покромсали файл на блоки и в четыре, восемь потоков обработали, а этот может только последовательно, и никак иначе.
stdin это не файл, а блочное устройство (как и многие файлы) =)

1. Чтобы покромсать файл на блоки, его надо вычитать, а если это не файл, а лента или любое другое устройство последовательного чтения, то несколько потоков уже и не всегда выгодно.
2. Какие другие архиваторы с произвольным доступом? Почти все другие архиваторы, ради более быстрого сжатия, стараются анализировать блок побольше (а то и файл целиком), создать словарь, и только потом уже сжимать.
(Именно поэтому алгоритм, компрессии использующийся в gzip, быстро стал поддерживаться многими модемами, а потом и различными другими устройствами)
3. Уже несколько раз упомянули про pigz, если это необходимо, который многопоточный, при этом обратно совместим с gzip
Как минимум, выгодно если скорость чтения с устройства выше, чем скорость сжатия.
Ну и даже создание словаря — вполне себе распараллеливаемая задача. Gzip же вообще такой возможности лишён :)
Собственно ответ уже был, лишь повторюсь, что всё зависит от компрессора. gzip сам по себе однопоточный, но у него есть мультипоточная реализация pigz.
А так поддержка ключей в 7-Zip для Linux есть:

-m{Parameters}: set compression Method
-mmt[N]: set number of CPU threads
-mx[N]: set compression level: -mx1 (fastest)… -mx9 (ultra)

Исходников Linux-версии тоже (пока?) нет. А автор по ссылке с официального сайта на вопрос о замене p7zip в будущем пишет, что не работает с Linux и ему будет сложно заниматься пакетированием всего этого добра.

Насколько я понимаю, Игорь обычно не публикует исходники до релиза.
Отличный архиватор, жаль что в Windows не интегрируется сам, как это делает WinRAR.
Ещё, кажется, нет возможности добавления данных для восстановления архива.
По скорости и степени сжатия превосходил WinRAR, раньше по крайней мере.
Ну и бесплатность добавляет популярности.
Спасибо разработчику.
Что вы имеете в виду под «в Windows не интегрируется сам»?
Интегрируется в контекстное меню, но не регистрируется сам в качестве приложения по умолчанию для соответствующих типов файлов. Т.е. с точки зрения многих пользователей архивы открывать всё ещё нечем.

Не помню умолчания при установке, но можно зайти в tools->options и там поставить галочки на все типы файлов которые нужны.

Да. А у WinRAR этого не нужно делать отдельно. В остальном — прекрасный продукт.

Насколько помню, если установку принудительно запустить под админом, то умеет. Или я что-то путаю

Верно, под админом надо делать.

А Shift-RClick — "открыть с помощью.." — "всегда открывать файлы такого типа" не катит?

Объясните условной бабушке данные действия по телефону. Почему просто не сделать привязку сразу при установке?
Потому что если каждое приложение при установке будет перетягивать ассоциации на себя, у вас будет анархия. Знаете, как сильно бесят обновления Windows, после которых она в очередной раз предлагает использовать Edge при открытии HTML-файлов? Зачем она это делает, я ведь уже выбрал Firefox как браузер по-умолчанию и как приложение для открытия HTML? А то, что вы предлагаете, привело бы к привязке Edge, ведь он же был установлен!
Но браузеры это настойчиво делают и будут делать, по политическим соображениям. И есть причины, почему у Вас в системе установлено более одного браузера.
А станете ли Вы устанавливать более одного архиватора? Понадобится ли условный WinRAR, если 7-Zip уже умеет распаковывать все необходимые форматы и наконец-то научится нормально интегрироваться?

У меня большинство архивов открывается Total Commander, 7-zip для редких случаев и shell menu как раз

Аналогично, в большинстве случаев использую для распаковки Far. Сжимаю всё же архиватором обычно.
Вот вам пример: у меня есть программа для просмотра JPEG-файлов, «Фотографии» (встроенная в Windows). Я ставлю Photoshop, который умеет редактировать JPEG-файлы. Он тоже должен прописывать себя как приложение по-умолчанию для JPEG? Чтоб вместо «Фотографий» у меня открывался условный Photoshop? Или «вы не понимаете, это другое»?

Photoshop, скорее всего, прописался по кнопке "Изменить" в контекстном меню JPEG-файлов. Перезаписав Paint, который был там по умолчанию.

«Фотографии» в Windows 10 весят как Photoshop десятилетней давности, не умея примерно ничего, и загружается 15 секунд. Поэтому у меня заменены на IrfanView, весящую на порядок меньше и умеющую всё. Конечно, IrfanView зарегистрирована как стандартный просмотрщик для всех типов изображений.
Редактор по умолчанию необязательно привязывать, обычно. Но tastes differ, как говорят англичане.
А станете ли Вы устанавливать более одного архиватора? Понадобится ли условный WinRAR, если 7-Zip уже умеет распаковывать все необходимые форматы и наконец-то научится нормально интегрироваться?
Я стану. Потому что распаковывать-то RAR 7-Zip умеет, а вот упаковывать — увы.
Скажите, а зачем вам упаковывать именно в RAR, если есть другие форматы?
Даже не знаю, как ответить на такой вопрос. Наверное, затем, что мне нужно?
Это звучит примерно как «я иду покупать молоток с синей ручкой, потому что у меня дома только с зелёной, а мне нужно забивать молотком с синей»
Ну если для вас архиваторы различаются только цветом, тогда извините.
А вы, чем ёрничать, лучше на календарь гляньте, какой сейчас год. Разница в степени сжатия давно помножена на ноль. Смысл информации для восстановления — тоже помножен на ноль, т.к. дисков, у которых могут отдельные сектора с данными посыпаться, просто нет — у флешек такого вообще не бывает (ну, кроме случая, когда вы записали на неё данные, которые вы решили прочитать лет через десять), у винтов теоретически бывает, но настолько редко, что нет смысла заморачиваться. По сути, самый удобный формат архивации вообще обычный zip, т.к. его поддерживает всё, что угодно, и вы будете уверены, что и вы, и любой ваш контрагент его всегда сможет открыть. Так что да, они только цветом различаются, ну ещё и скоростью архивации. И в этом плане и RAR, и 7-zip явные аутсайдеры.
у флешек такого вообще никогда не бывает
Три раза «ха».
у винтов теоретически бывает, но настолько редко, что нет смысла заморачиваться
UER у обычных HDD 1x10^-14, что, вообще говоря, не так уж мало.
По сути, самый удобный формат архивации вообще обычный zip, т.к. его поддерживает всё, что угодно, и вы будете уверены, что и вы, и ваш контрагент его всегда сможет открыть.
Это называется не «самый удобный», а «самый универсальный».
Три раза «ха».

Даже если у вас это и произойдёт один раз на несколько тысяч операций, вам намного будет проще ещё раз свой файл туда записать, нежели каждый раз добавлять туда избыточную инфу для восстановления.
UER у обычных HDD 1x10^-14, что, вообще говоря, не так уж мало.

UER на HDD, это в общем случае не безвозвратная потеря данных, обычный винт задолго до возникновения невосстановимой ошибки выполнит релок проблемного сектора.
В общем, не надо лишней паранойи, а то так и до шапочки из фольги дойти можно. В конце-концов, копия бэкапа на другой накопитель решит 100% возможных проблем с накопителем, а не 0.1%, которые решает добавление избыточной информации.
Даже если у вас это и произойдёт один раз на несколько тысяч операций, вам намного будет проще ещё раз свой файл туда записать
Это при условии, что у меня этот файл остался.
UER на HDD, это в общем случае не безвозвратная потеря данных, обычный винт задолго до возникновения невосстановимой ошибки выполнит релок проблемного сектора.
Это не тот UER, что в SMART, это вполне конкретная характеристика. И да, мне будет не легче, если винт сделал reloc — информация-то потеряна.
Это не тот UER, что в SMART, это вполне конкретная характеристика.

Это тот самый UER. Но не суть важно. Как я выше дописал, если данные действительно важные, просто делайте две копии архива на разных накопителях. С накопителем может произойти всё, что угодно, и с вероятностью примерно 99.9% это будет отнюдь не то, от чего вам поможет примочка в виде добавления избыточности в архив.
У всех, советующих делать дополнительные копии, хотелось бы спросить — где вы деньги на дополнительные накопители берёте? Да, recovery record не панацея, и не замена бэкапа, но значительно лучше, чем ничего.
где вы деньги на дополнительные накопители берёте?

Эм… а на календарь вы смотрели, когда я просил? 2021-й год, напомню. Четырехтерабайтный винт стоит $100. Потратьте как-нибудь то время, которые у вас уходит на возню с архивами/архиваторами, просто на приносящую деньги работу, и купите себе несколько таких. И я не ошибусь, если скажу, что четыре терабайта способны вместить весь контент, который вы там у себя можете нагенерировать, если это не куча видео и фото. Но видео и фото, к слову, это такие замечательные форматы, которые
а) не нуждаются в архивации
б) без особых проблем перенесут все те UER, если их не архивировать :)
Да, recovery record не панацея, и не замена бэкапа, но значительно лучше, чем ничего.

совершенно незначительно, если точнее. В том-то и дело.
Если брать для себя новый и современный привод — да, если брать LTO5/6 б/у — нет.
Ну как бы сказать… Посмотрел на авито, там от 20к и до 80-ти. Не сказать чтобы дёшево. Ну и надёжность подобного решения вызывает вопросы, приводы старые, и читать их скоро может стать негде.
Да все равно дорого, к тому же возни много, по сравнению с обычными винтами.
UER у обычных HDD 1x10^-14, что, вообще говоря, не так уж мало.

То есть на обычную информацию вам плевать, зато в архиве всё классно?
Суть в том, что хочется поставить один архиватор. Вы выбрали winrar, другое человек выбрал 7zip. И этого достаточно, чтобы распаковать и тот и другой архив, если его вам прислали.
Но вот два архиватора ставить уже не нужно, и в этом — плюс.

Если бы при установке архиватора было окно "Выбрать 7-zip стандартным приложением для архивов?" — вопросов бы не было совсем. Показывать каждый раз — это перебор, разумеется.

Мне кажется, гипотетической бабушке проще сделать клик с шифтом, чем искать в настройках нужную галочку: ассоциировать себя с 7z, со всеми архивами, выборочно с такими-то архивами… проще кликнуть)

Настоящие_программисты_не_пользуются_пробелом. Бабушки_не_пользуются_шифтами. Обычно.
Из любого правила, конечно, есть исключения, например «Бабуля КОБОЛ».

Грейс Хоппер
Если вы про интеграцию в проводник, значит вы установили 7-Zip 32-bit x86 на Windows x64.
64/64, только что проверил.
Запустите от администратора
И я о том же. Запустить от администратора, и не факт что поможет, найти пункт в GUI и привязать оттуда, привязать вручную к нужным расширениям, смахнуть пыль с любимого бубна — всё это не про пользователей — у них либо «работает», либо наоборот. У WinRAR интеграция «работает», у 7-Zip пока не совсем. Это, на мой взгляд, причина, почему платный WinRAR всё ещё популярен.
Хз зачем нужна эта привязка. Обычно все ограничивается контекстным меню распаковать тут и всё.
Не все пользователи владеют контекстным меню. Вы же запускете файл .docx почти наверняка не через выбор пункта «Открыть» или «Изменить» в контекстном меню, да и искать настройку привязки типов файлов в Word'е не приходится, файловые ассоциации регистрируются автоматически при установке.
Если уж работа с файлами в Windows построена на их типах и привязанных к ним стандартных открывалках, почему бы просто не сделать как все, особенно учитывая отсутствие в системе мало-мальски достаточного собственного архиватора. Иногда складывается впечатление, что Microsoft состоит в негласном сговоре с разработчиками системного и прикладного ПО и именно по этой причине в системе за тридцать лет отсутствуют или находятся в зачаточном состоянии некоторые элементарно необходимые вещи.
Не все пользователи владеют контекстным меню.
Если пользователь владеет установкой ПО, но не владеет контекстным меню, то он либо лютый консольщик, либо, простите, олух.
почему бы просто не сделать как все
Как все (в наши дни) — это весьма вероятно Electron-приложение, которое устанавливается в AppData, зачастую даже без возможности выбора.
в системе за тридцать лет отсутствуют или находятся в зачаточном состоянии некоторые элементарно необходимые вещи.
Строго говоря, ОС должна уметь только загрузиться и дать возможность пользователю что-то запустить. ОС не обязана быть комбайном, который готов для любой вообразимой задачи, она должна быть достаточно компактной. В противном случае получим новый виток «Объёмных объектов» (3D — это же круто!), OneDrive, который нельзя удалить просто так (но ведь все пользователи хотят в облако фотографии котиков складывать!), возможность удалить «Калькулятор» (пф, у каждого смартфон в кармане, зачем им на компе считать?), но не «Карты» (а вдруг тот самый смартфон разрядится, а про сайты человек не в курсе) и так далее. Нет уж, давайте ОС будет давать в первую очередь возможности, а не решения.
Выше уже предлагал такой умозрительный приём — берём гипотетическую бабушку, получившую от внучика архив 7z. Вам досталась почётная задача объяснить бабушке, как архив открыть. Вы всего за полчаса сумели пошагово провести бабушку через процедуру скачивания и установки нужного ПО. Теперь остались мелочи — собственно распаковать архив и убедиться, что следующий архив также успешно распакуется.
Если бабушка за полчаса смогла найти (под руководством) оф.сайт, скачать и установить программу, то двойной клик на неизвестном (пока что) *.7z файле — выбрать 7zip и просто не снимать галочку «Всегда использовать это приложение для открытия .7z файлов» она освоит ещё минут за 5-7.
Возможно, но зачем?
Хорошо, ответный вопрос: а зачем внучок ей отправлял 7zip архив, если не уверен, что бабушка сможет его открыть? Почему не *tar.gz сразу, пусть помучается с двухступенчатой распаковкой?
Вроде как все околоайтишные люди знают, что если не уверен, есть ли у той стороны нужное ПО — отправляй в максимально распространённом/примитивном формате.
Потому что внучик продвинутый, а в архиве несколько сотен файлов — их отправить поодиночке будет несколько сложнее.
Потому что внучик продвинутый
если он «продвинутый», то он либо заранее узнаёт про наличие 7zip, либо сразу использует ZIP для сжатия. Учитывая контекст, он отправил что-то вроде архива фотографий или песен (вряд ли бабушке понадобится что-то более сложное, в противном случае она тоже продвинутая и уже имеет у себя 7zip), и для этой цели простого ZIP-архива более чем достаточно. А откроется он средствами самой Windows.
Продвинутый бы выложил фоточки в гуглофотках, и отправил бы бабуле ссылку. А это какой-то извращенец. Может, он ей вообще не внучок, а обхаживает, чтобы квартиру переписала?
Ну вот почти что случай из жизни — присылают не ссылку на гуглофотки со свадьбой, а избранные фото, чтобы восприимчивую бабулю не доконать современностью мероприятия.
По-моему, скопировать избранные фото в другой альбом гуглофоток — это даже проще, чем сделать архив и отправить его бабуле.
Мы вроде бы обсуждали недостаточную (на мой взгляд) интегрированность 7-zip, а не гуглфото. 7-zip появился в 1999 году, гуглфото — в 2015.
Интеграция 7zip в Windows есть, причём даже лучше встроенного в Windows архиватора Zip. А то, что для этого надо сделать примерно 5 кликов мыши — совсем незначительный минус. Да, неприятно, но зато не будет, например, так, что VHD и ISO файлы стали открываться в 7zip, а не VmWare и каким-нибудь Daemon Tools соответственно.
Мы вроде бы обсуждали недостаточную (на мой взгляд) интегрированность 7-zip, а не гуглфото

Гуглофото тут приводится в контексте «ну и фиг с ней, с интеграцией, в 2021м-то году».
Опытный пользователь, если надо, быстро настроит. Неопытный, вроде упомянутой бабушки, никогда в жизни с тем 7-zip и не столкнётся.
В итоге отличный бесплатный продукт с двадцатилетней историей не становится единственно необходимым в классе из-за мелкой особенности.
Я вообще не знаю, что такое «единственно необходимый» в отношении архиваторов в 2021-м году. Мне бы, например, не пришло в голову что-то сжимать в формате 7-zip сейчас, равно как и rar, например. Я сделаю обычный zip-архив стандартными средствами ОС или файлового менеджера, и я буду знать, что тот, кому я отправляю архив, его сможет открыть без какого-либо дополнительного софта.
Вы пытаетесь натянуть сову на глобус. Всегда есть Anydesk\TeamViewer.
Конечно есть. Ещё полчаса — и программа удалённого управления скачана и запущена.
И главное — если бы исходно программа привязалась с целевым файлам, удалённое управление не понадобилось бы.
Ещё полчаса
Всего полчаса + пара минут, если вы установите бабушке 7zip через удалённое управление, а не «установи то, сё, пятое, десятое, потрать на это несколько часов, а я потом за 3 минуты всё настрою»
Этот вопрос вменяемыми внучками решается в момент приобретения пк бабушке. Самые вменяемые еще и не форточки бабушке оставят, ибо пк для некомпетентных должен быть неубиваем априори и включаться/выключаться одной кнопкой как любой электроприбор.
Пример притянут за уши. Если вы знаете что получатель плохо умеет работать на компе, то вряд ли вы будете усложнять ему жизни запаковывая файлы в 7zip архив. А уж если это ваша бабушка то проще иметь удалённый доступ и самому положить все куда надо. Опять же можно сделать sfx архив.
я расскажу, как запустить anydesk и сделаю всё сам точными отработанными движениями
Zip встроен в Windows не помню точно когда, но в Windows 95 уже был. Да, там не было криптографии, но сжать папку в один файл можно было. И, кстати, при установке WinRar этот пункт меню автоматически пропадает, и на месте него остается привычный многим пункт меню с тремя книгами на иконке. Начиная с Windows 98 можно пользоваться документами в zip-архиве не распаковывая архив полностью.

А вот прописывание дефолтных обработчиков на общепринятые форматы файлов меня вымораживает. Я как-то лет 5 назад из-за этого выпилил очень хорошую программу Audacious из репозитория сборки, которой пользуются каждый день очень много человек. Этот Audacious прописал себя открывать по дефолту на mime-тип inode/directory. Ох сколько было мата…

Так то, разработчики Audacious наверняка думали, что это удобно загружать в музыкальный плеер всю папку целиком и потом рекурсивно найти аудиофайлы всех форматов. Но они упустили момент, что папки бывают не только с музыкой, а еще и с документами и вообще со всякими файлами. И видя как открываться аудиоплеер, когда тыкаешь по папке — это как-то сбивает с толку.

в win95 как-то рановато, минимум в win2000, и то не факт

Если точнее, то в Win 98 она появилась, только не в стоковой, а с пакетом расширения Windows 98 Plus.
Нет. Встроенный в Проводник архиватор появился в Windows XP.
В Windows Me уже была встроена поддержка ZIP. В Windows 98 доустанавливалось вместе с официальным Windows 98 Plus.
В ME вроде только распаковка была. А ставить Plus — это уже лишние телодвижения, с таким же успехом можно было и WinZIP поставить.
«Да, там не было криптографии, но сжать папку в один файл можно было.»
Там нет ничего из расширенной функциональности — разбиения на тома по размеру, управления степенью сжатия, сохранения/восстановления даты/времени, и много чего ещё.
Как и во многих других случаях, IMAPI например, складывается впечатление, что у МС есть отличные программисты, умеющие реализовать полноценно функциональность, доступную в сторонних продуктах, развивающихся на протяжении десятилетий, но при интеграции в ОС большая часть уже реализованной функциональности остаётся недоступной из-за криворукой реализации соответствующего GUI. При этом недостающая функциональность может быть вполне доступна из командной строки или хитровыделанного API, но это совершенно бесполезно для большинства пользователей.
Ну знаете, в Windows и полноценного текстового редактора нет предустановленного (только WordPad, а может и его выпилили), а уж он-то чаще нужен пользователям, чем «разбиение архива на тома по размеру, управление степенью сжатия, сохранение/восстановление даты/времени, и много чего ещё». А «Блокнот» даже номера строк не показывает слева, не говоря о подсветке синтаксиса (в отличие от какого-нибудь gedit из линукс-мира).
Это другое. К примеру, у Вас есть дискета и флешка с малым свободным объёмом, и нужно перенести на другой компьютер, не подключённый к сети, данные. Есть даже встроенный архиватор, но как ему объяснить лимит на размер архива? Вручную подбирать файлы и сжимать по частям непродуктивно, т.к. степень сжатия сильно варьируется в зависимости от характера файла. В итоге либо придётся очищать флешку, либо искать другой архиватор, то и другое требует лишних телодвижений, в любом случае встроенный архиватор становится бесполезным. Пример может быть и несколько устаревший, но и проблеме уже не первый десяток лет.
нет возможности добавления данных для восстановления архива.

Вы про добавление CRC-суммы к каждому блоку данных, чтобы можно было идентифицировать испорченные блоки не теряя архив целиком? Так это, вроде как, в формате 7z встроено by-design.
Надо полагать, хочется как в winrar, чтобы можно было исправить испорченные блоки.
Как? Ок, я добавлю в архив 5% избыточных блоков и поменяю 50 рандомных байтов равномерно во всем архиве. Как он сможет по 5% восстановить 100% данных?
С помощью силы математики конечно :) В комментах долго рассказывать, но в сети много информации на эту тему вот например статья на Хабре
если 5% это больше чем 50 рандомных байт, то так и сможет. Вы бы документацию почитали.

В WinRAR есть возможность разбить архив на N частей, из которых любых M достаточно для распаковки (либо не разбивать архив, а просто добавить в файл избыточных блоков). 7-zip из коробки так не умеет, но можно создать файлы с информацией для восстановления с помощью MultiPAR.

MultiPar/source/*.7z

Автор знатный наркоман.
Именно про добавление избыточной информации.
Однажды, довольно давно, по моей вине очередной раз была задержана научная работа — сжал архиватором небольшую папку с исходниками проекта вместе с большим файлом экспериментальных данных с установки и впервые не протестировал архив — очень торопились. Как выяснилось позже, файл данных можно было легко получить снова, а исходники не распаковались из-за единственного сбойного сектора на hdd. Автор исходников стоически отнёсся с происшествию, сообщил, что работа уже сгорала в пожаре и однажды была украдена из лаборатории вместе с компьютером.
С тех пор предпочитаю добавлять информацию для восстановления в архив с важными данными. Потеря нескольких процентов объёма с лихвой компенсируется увеличением стойкости архива к повреждениям, превышающем обычную проверку CRC.
Люди делятся на три типа, кто не делает бекапы, кто делает бекапы, и кто уже делает бекапы. Вы из первого типа в третий не перешли, увы.
Потеря нескольких процентов объёма с лихвой компенсируется увеличением стойкости архива к повреждениям, превышающем обычную проверку CRC.
Жёсткий диск очень любит сыпаться последовательными блоками, так что «нескольких процентов» мало, надо или приличные 15-20, или просто сделать копию на другой носитель.
Плохо помните классику.
Те, кто не делает бэкапы
Те, кто уже делает
Те, кто уже делает и проверяет их целостность.
Видимо, у нас разные источники :)

Спасибо пользователям Windows за бета-тест ^^

Пожалуйста.
Поддерживаю. Peazip — швейцарский нож. Столько параметров нет ни в одном другом GUI архиваторе. 7-ZIP и рядом не стоит.
он даже winrar переплюнул?
Столько параметров нет ни в одном другом GUI архиваторе.

А сколько из них нужных параметров?

Интересно зачем? Это как портированные фар когда есть мц

Джаст вай нот? Они похожи только внешне. Да и MC вроде бы не особо развивается, а у Far куча плагинов.
mc 4.8.26 (10 января 2021)
У mc внутри куча интеграций и кастомных настроек.
Кто привык — тот и будет юзать FAR. Лично мне он отвратителен.
Они почти ровесники. Пользуюсь Far'ом почти четверть века, пока отвращения не вызывает, правда на Windows. Пользовался MC без отвращения, но и без желания заново вникать в тонкости. Благо Far всё-таки портировали, как и MC, так что у всех есть возможность использования предпочитаемого инструмента.
Я с вами согласен. Но мне ближе даже нортон и волков коммандеры.
Тут кто к чему привык). Кто-то пользуется и тем и тем, кто-то совсем другим.
Понимаете, продукты делают ± одно и то же. Но когда ты привык к логике действий и шоткатов mc и пробуете тот же фар, то начинается попаболь из-за того, всё делается по другому, другие шоткаты, другие плагины и интеграции. Ровно, как и наоборот.

ps. лол, мне за 5+ лет комментирования на ресурсе каждый раз минусят карму за комменты про FAR). Кто-то видимо очень ярый фанат.
Забавно, когда это происходит молча.
так и far завезли уже в linux
far под линукс и под windows (+conemu) — довольно разные вещи…
Вопрос не про разные вещи же.

Архиваторы сейчас как программы для записывания CD — в основном утратили свою основную функцию. Пользователи их используют, в основном, просто чтобы получить один файл, вместо рассыпухи и куда-то его переслать. Соответственно лучше тот, который быстрей, т.к. проще скачать в полтора-два раза больше, чем ждать пока оно распакуется.

Не правда. Рассыпуха рассыпухой, но и сжать всю эту рассыпуху тоже полезно. Даже 30% экономии места и траффика — это прилично

Может вы имеете ввиду системное, сетевое применение? Я специально упомянул "пользователей". Действительно массивный контент (фото, видео) и так сжат по максимуму. А мелочь? Какая разницу сколько она там весит.

Архив из тысячи мелких файлов скопируется на флешку гораздо быстрее, чем папка с распакованными файлами.
Сейчас к вам прибегут свидетели сетевых хранилищ и расскажут, что флешкой они пользовались в последний раз в 2010м.
Как говаривал знакомый — лучшая флешка это карандаш. Облака тоже горят, про вчерашний пожар в датацентре, кажется, уже три статьи.
В облако архив упорхнёт тоже быстрее, чем папка.

Лучшая флешка — это диверсификация хранилищ.

Так в сетевые хранилища цельные архивы зачастую тоже быстрее копируются, по сравнению с рассыпухой из сотен файлов :)
Мне проще распаковать 40+ гигабайт в 200, чем эти 200 скачать.
Архиваторы позволяют зашифровать пересылаемый файл.

Это не их основная функция. Для шифрования всегда есть gpg, openssl и прочие утилиты.
И тот же tar, например, не умеет ничего шифровать сам.

Ну, попробуйте объяснить слабой в компьютерах и инглише китаянке, как ей быть с присланной документацией, зашифрованной с помощью перечисленных вами утилит. Вместо даблклика по файлу и ввода пароля в окошке. Поэтому уверен, что большинство пользователей для шифрования использует именно архиватор.

если эта гипотетическая китаянка не умеет читать то какого простите ляда она сидит за компухтером?
а так файл зашифрованный тем же gpg по даблклику в винде предлагается рассшифроваться клеопатрой при наличии оной. удобство одинаковое.
здесь вы скажете что архиватор у неё в 99% случаев уже стоит а win gpg пакет нет… ну так это вопрос популярности а не удобства. и уж точно не имеет отношения к гипотетической китаянке

Решение где это всё интегрировано просто удобнее. Например, вам не нужно расшифровывать и разжимать весь поток данных, чтобы посмотреть какие файлы там хранятся. Вы можете опционально зашифровать имена файлов, или оставить их в нерасшифрованном виде, что тоже бывает удобно. Сжатие также работает лучше в 7-zip, так как он для разных типов файлов в архиве умеет автоматически применять различные фильтры для повышения степени сжатия. Если архивировать всё в tar, а потом запаковывать в xz, то сжатие может оказаться значительно хуже, чем если бы всё архивиловалось и сжималось в 7z.

опять же вопрос насколько хорошо сжалось это одно и я с этим не спорю. удобство это другое
я про удобство
гуёвый ark создаёт из папки архив одним кликом. и юзверю знать не надо чем отличается .7z от .tgz (.tar.gz)
главное чтобы админ заморочился и поставил необходимый набор софта. за что кстати я в винде и любил 7-zip. он открывал любые архивы и не только архивы

Вы не поняли. Не интегрированное решение, а такой «бутерброд», будут делать много лишней работы. Нельзя посмотреть список файлов без расшифровки и распаковки всего потока. Невозможно сделать запароленный архив с видимым списком файлов. Одно специализированное решение, которое совмещает в себе все нужные функции, может позволить себе быть более гибким в этих вопросах.

Это как новый протокол QUIC (поверх которого работает новый HTTP3). Он совмещает в себе функции TCP, TLS, плюс мультиплексирование потоков в стиле HTTP2. И это даёт ему множество преимуществ по сравнению со старым решением, где надёжная доставка, шифрование и мультиплексирование делалось отдельными технологиями.

image
Это как новый протокол QUIC (поверх которого работает новый HTTP3).

Эм, я вижу такое же количество слоёв. Только QUIC стал жирнее, чтобы монополия гугла над интернетом лучше просматривалась.
Разработкой QUIC занимается целый ряд заинтересованных организаций под флагом IETF. Google только предложил первую версию в 2013 году. С тех пор разрабатывается всеми заинтересованными компаниями, и сильно отличается от того, что предлагал Google. И нет, у Google там не большинство голосов. Только 8 лет спустя все пришли к какому-то консенсусу и основная часть стандарта уже почти закончена (но продолжается работа по расширениям типа пересылки UDP-подобных пакетов через QUIC-соедиение).

Визуально кажется что уровней столько же, но UDP там используется только для совместимости с существующими сетями, потому что только так сегодня можно добавить новый протокол транспортного уровня без замены всего железа по всему миру (что близко к невозможному). То есть его роль только в совместимости с существующими сетями. Сам по себе QUIC несёт себе функции TCP, UDP, TLS и мультиплексирования нескольких потоков через одно соединение (что ранее было частью HTTP/2), с кучей новых классных возможностей. То есть раньше часть задач транспортного уровня был вынужден брать на себя HTTP/2 (мультиплексирование нескольких потоков), что было не очень логично, и оно работало плохо из-за всей этой матрёшки (потеряли один пакет одного потока — застряли сразу все потоки), сейчас это ушло куда и положено, на новый транспортный протокол в лице QUIC (который ещё и заменяет TLS, так как только при такой интеграции можно избавиться от недостатков старой связки TCP+TLS+мультиплексор потоков).

Ну, теоретически можно было бы взять стек UDP/DTLS/SCTP/протокол приложения сверху.


DTLS шифрует пакеты SCTP, SCTP мультиплексирует потоки и обеспечивает надежную доставку (не страдая при этом проблемами TCP, когда один пропавший пакет тормозит всю очередь). Или не обеспечивает, если конкретно этому потоку такая доставка не нужна и он прекрасно живет с потерями. Или обеспечивает со стратегией "если за секунду пакет не ушел — выкидываем". Там много настроек.


Приложение работает уже поверх SCTP с абстракцией "много надежных зашифрованных потоков". Но у этого стека есть фатальный недостаток.

Можно было, но у SCTP+UDP были некоторые недостатки, которые в том числе хотелось решить. QUIC быстрее устанавливает защищённое соединение, и он умеет в миграцию соединения если клиент перемещается из сети в сеть (был на мобильном интернете, стал через Wi-Fi и т.д.), наверняка и какие-то другие преимущества есть. Вы посмотрите сколько реализаций QUIC в разработке. Протокол интересен далеко не только одной Google. Это совместное усилие, потому что преимущества того что предложил Google 8 лет назад были очевидны всем, поэтому идею и подхватили и начали развивать вместе. И это прекрасно, так как это как бы повышает шансы, что стандарт пишется не в стол, а будет на самом деле применяться.

Синдром NIH — это когда какая-нибудь Apple делает свой изначально проприетарный ALAC, который совершенно непонятно зачем вообще создавался, потому что он буквально во всём хуже FLAC, который был создан раньше и был изначально свободным.

А если есть возможность предложить что-то лучшее, чем уже существует, то это уже не NIH, а развитие технологий. Если при этом компания кооперируется с другими заинтересованными сторонами для того, чтобы получить ещё более продуманный стандарт — это ещё лучше.

Тут больше претензия в том, что на выходе вместо модульных частей получается монолит, который хорош только в том, подо что его затачивали.


Да, разумеется, слоистое решение не идеал в плане эффективности. После DTLS можно не делать SCTP-хендшейк, например, а сразу инициализировать протокол каким-то состоянием. Насчет миграции, кстати, не согласен. DTLS в такое должен уметь, если правильно написать UDP-слой. Но это можно дорабатывать, сохраняя модульность. Заодно и реализации этих протоколов нормальные появятся, а не, упаси господи, usrsctp. Еще я с некоторым подозрением смотрю на попытку переизобрести TLS. Понятно, что там учтен опыт нахождения дырок в оном, но все же.


А пока, как я понял, на выходе получается вишмастер, который можно воткнуть, если приложению нужно мультипоточное надежное соединение. А если нужно чуть другое — уже нельзя.

Например, вам не нужно расшифровывать и разжимать весь поток данных, чтобы посмотреть какие файлы там хранятся.


Индекс-файл может создать и tar. Просто это указывается отдельным параметром.

И результат будет отдельным файлом, при этом решающим только задачу «получить список файлов в архиве без распаковки». Смещения начала файлов в нём не указаны, так что достать один файл он вам не поможет, даже если вы используете несжатый архив. Во всяком случае, именно так выглядит результат создания index‐файла с помощью --index-file.


Вообще некоторой доработкой формата можно было бы добиться нужного эффекта: просто научите tar дописывать этот index‐файл в конец архива (для совместимости: не в виде файла, а просто в виде некорректных данных после конца архива) и передавать xz параметр --block-list с такими значениями, чтобы один файл соответствовал одному блоку. Но это мало кому нужно, и вызывает необходимость что‐то делать с разными особыми случаями вроде «что делать, если файл обрезали после того, как tar передал --block-list но до того, как он начал запаковывать файл» (вопрос, в принципе, решаемый, если вы засунете xz внутрь tar или сделаете так, чтобы xz принимал на вход поток команд, а не просто поток данных).

На вкус все фломастеры одинаковые, не хочу спорить ради спора, но сложилось так, что винрар, офис, адобридер стоят на 99% компьютеров, поэтому файлы в этих форматах у 99% не вызовут затруднений. Поэтому шифровать для себя можно хоть трукриптом в контейнер, а если планируется передавать файлы, то — архиватором…
Винрар платный как бы.
А офис и акробат бесплатные?
Есть бесплатные LibreOffice и SumatraPDF =)

Рулю службой поддержки пользователей и с лютой завистью смотрю на таких счастливых обитателей мира единорогов и радуг, как вы :) без обид, но 95% пользователей ПК независимо от национальности просто не поймут, что вы им предлагаете. А мне не нужно нести просвещение в массы, мне нужно убедиться, что проблема клиента решена наиболее простым и быстрым способом. Если бы я каждый раз заворачиваться в белый плащ и орал "ты дура тупая" на каждую китаянку — я бы давно свой выдающийся ум демонстрировал не коллегам, а другим нищим бездомным бомжам на привокзальной площади.

Вот да. Мои бэкапы лежат в зашифрованных 7z-архивах (причем, жмутся выборочно, например, образы виртуалок ради экономии времени лежат в архиве без сжатия, а документы лежат в другом архиве и сжаты). Мне банально удобно, что я могу двойным кликом открыть бэкап, ввести пароль, и вытащить, например, какой-то один файл, и для этого не нужны никакие клеопатры, всё делает одна утилита.

И, вроде, я не тупая китаянка, но в упор не понимаю, зачем бы мне устанавливать и использовать сразу несколько утилит, если от этого я не получу ровным счётом никакого удобства или выигрыша.
Запись на CD активно используется в медицине, те же томограммы. Если писать на «свисток», то через какое время инфа улетит? А так CD можно в конвертике хранить годами. Так же и с архиваторами.
Мой CD с МРТ зубов кажется так никто и не открыл. Ссылку на облако кинули мне на почту и в клинику ))
Скорее КЛКТ.
А так CD можно в конвертике хранить годами.

Если бы ещё и приводы CD годами хранились…
Вот чем реально 7zip хорош, что у него с рождения не было проблем с кодировками на любых OS.
Зато доавбить сохранение базовых прав, ссылок и прочего они не могут. Как можно было сноля сделать архиватор и не заложить в него ссылки, специальные типа файлов и сохранение прав?!

С учётом появившейся только в 20й версии поддержки Linux и отсутствием поддержки macOS не вижу ничего странного. В виндовых архиваторах такого почти нигде нет.

Билды под линукс уже давно были и 7z есть во всех репах. Реквесты добавить сохранение метаинформации ещё 10 лет делали. Самое главное, что там делов-то всего ничего и уже была пара пересмотров формата файлов. Была бы метаинформация, проект бы гораздо веселее развивался — был бы смысл подключаться другим разработчикам. А так на всё вопросы автор 10 лет отвечает, — «я ничего в этом не понимаю, этого не будет», — что круто всех обламывает.

Под Linux и macOS есть p7zip. Это отдельная утилита, разработка которой приостановилась лет 5 назад (но в некоторых дистрибутивах уже перешли на его форк).
В остальном — да, всё так.


С другой стороны, а зачем в Linux нужен именно 7z? Есть же xz-utils, использующий те же алгоритмы сжатия (LZMA/LZMA2). В комбинации с tar он решает задачи сжатия и архивации данных.

1) Сделайте листинг большого xz-архива на десяток гигабайт. Особенно в каком-нибудь файловом менеджере.
2) Распакуйте 1 небольшой файл из 32 GB архива xz.
3) Сделайте инкрементальный архивы, дельта архивы, обновление содержимого архивов и т.п. под xz.
4) У вас Linux, но вам нужно передавать архивы и работать с ними под Windows.
6) Вы хотите гибко управлять компрессией.
7) Вам нужно user-friendly шифрование, чтобы самый тупой сотрудник потом можно это расшифровать под любой OS.
8) У вас Windows, но вам нужно получать архивы из Linux.
9) У ваших заказчиков Windows и вам нужен какой-то user-friendly архиватор для взаимодействия с ними.
10) Вы хотите удобно и кроссплатформенно работать с zip-архивами.
11) Вы хотите удобно распаковывать JAR, RAR, CAB и тому подобное.
12) Для вашего проекта нужна серьёзная работа с архивами из собственной программы.

7zip на голову лучше вообще всего и по всем параметрам. Единственный минус — отсутствие поддержки сохранения метаинформации POSIX.

Замените xz на pixz. Он индексирует tar при сжатии и сжимает блоками для быстрой частичной распаковки.

И как мне из файлового коммандера или из винды листинг архива просмотреть? Вы же в курсе, что он в своём формате это к архиву добавляет?

А 7zip не в своем формате сохраняет?


Из консольки можно посмотреть. Или поискать/написать плагин для mc/total commander. Благо для mc дальше баша лезть не придется.


Замечание было лишь по первому пункту. Если вам часто нужен листинг, то используйте форматы с индексом.


Если вы не сами архивы создаёте, а получаете извне, то у вас и выбора то нет. Что прислали с тем и работаем.

И какой именно кросплатформенный архиватор с индексом, поддержкой многопоточности и шифрования мне нужно использовать? ;)))

Ну я же не призываю вас отказаться от 7zip. Мы тут рассматриваем возможные сценарии использования. Где-то 7zip хорош, где-то просто не имеет нужных функций.


Например вам нужно публичным ключём зашифровать архив.
Или подписать его.
7zip умеете?

отсутствие поддержки сохранения метаинформации POSIX.

Там на самом деле достаточно было бы хранить только executable биты и все…
архив без отказоустойчивости бессмысленнен по определению
ну да, вы скажете давайте сделаем ещё копию архива и пусть оно будет децентрализовано
так и это плохо, ибо тогда архив нужно бить на части или если архив повреждён, то что же это тащить весь по новой или всё же дотащить битую часть?
и т.д. и т.п.

на календаре наминутачьку 2021 и этот ваш севензип не может ничего логически актуально действительно нужного
извините, но… нет

п.с.: да, я за рар и ничего более функционального пока не придумали
архив без отказоустойчивости бессмысленнен по определению

Отказоустойчивость сейчас реализуется другими средствами. Ну и 10 лет назад я паковал в RAR с 5% для восстановления, ни разу не понадобилось. Файл или целиком пропадал вместе с носителем, или жив-здоров и лежит на диске.
Проблемы с битыми архивами остались где-то в 90-х и нулевых, вместе с дискетами и оптическими дисками. То есть то что вы описываете к 2021 году лишь стало менее актуальным. А вот полноценный бэкап не утратил актуальность: риск полного отказа HDD или SSD хоть и мал, но всегда есть. Но это делается другими средствами.

Соглашусь, что как опция такая функция не помешала бы. Но на мой взгляд свободность 7-zip перевешивает это преимущество RAR.
Проблемы с битыми архивами остались где-то в 90-х и нулевых
Ваши бы слова да богу в уши.
Флэшки — крайне ненадёжный носитель.
Сеть — до сих пор порой есть вероятность скачать битый архив (а не у всех безлимитный гигабит, чтобы перекачивать, знаете ли).
Даже у HDD далеко не нулевая вероятность ошибки чтения/записи, а остаётся она на том же уровне, а объёмы-то растут.
А для чего это надо 80% пользователей?
А чем вы файлики архивировать будете? Zip? Так он плохо архивирует, медленно и криво. Rar, прости Господи? Так он денег стоит.
7zip это сейчас единственный нормальный бесплатный опенсорс архиватор.
Я спрашивал, для чего 80% пользователей «ссылки, специальные типа файлов и сохранение прав»? Правило Парето 80/20…
WINRAR всегда был неограниченно условно-бесплатным. Ну окошко, ну и что… Тем более, что лечится.
Вы, когда заказчикам работу сдавать будете, то так и напишите в ТЗ и документации?
80% нужен удобный интерфейс и кроссплатформенность. Оставшимся — плюшки и свистелки. Сейчас эти два множества пересекаются только на 7zip.
WINRAR всегда был неограниченно условно-бесплатным.

В СНГ отношение к условно-бесплатному такое, что спасибо Рошалу он сделал для СНГ это бесплатным по умолчанию.
Но зарубежом к этому относятся серьезнее, особенно если не дома. И закупить winrar для компании в 10к сотрудников внезапно совсем недешево.
В СНГ отношение к условно-бесплатному такое, что спасибо Рошалу он сделал для СНГ это бесплатным по умолчанию

Не совсем так, в этом вина финансовой безграмотности разработчика. В нулевых Винрар (да и почти любое другое приложение) стоил 30 долларов и для людей было слишком дорого платить 20% зарплаты всего лишь за архиватор. До разработчиков только сейчас стало доходить, что лучше получить по доллару, но с каждого, чем поставить запредельный ценник, который оплатит доля процентов аудитории — игры в Стиме, приложения в Плэймаркете стоят от доллара, а Офис даёт плюшки в виде 6 ТБ и люди не столько покупают офис, сколько эти терабайты… Это как с налогами — ты увеличиваешь налоги, а поступления в бюджет внезапно уменьшаются… Если бы Винрар тогда стоил вменяемые 1...3 доллара, и был простой и удобный механизм оплаты без похода в банк, то даже школьники, наверное, честно покупали лицензию.
В СНГ отношение к условно-бесплатному такое

Вовсе не только в СНГ. Сколько встречал западных пользователей WinRAR — все использовали его так же бесплатно. У них покупка WinRAR даже своего рода «мем».
Ну окошко, ну и что…

А потом проверка и штраф.

Про те 80% и не говорим

Вроде как по крайней мере сохранение прав (те что устанвливаются chmod) работает. Только что специально проверил предоставленной бета-версией. Не знаю как оно в p7zip было.
Интересно. Нужно погонят. Если ещё хотя бы ссылки будут работать, то это просто праздник какой-то.
Ссылки тоже проверил. Не сохраняются. Но непонятно как их сохранять, если они куда-то за пределы архива указывают. Только если все ссылки на какие-то файлы внутри архива, тогда понятно. Думаю, наверняка можно добавить такое расширение.

Символическая ссылка — это технически обычный файл, содержащий путь к тому файлу, на который он ссылается и имеющий атрибут, указывающий, что это символическая ссылка. Чтобы сохранять их вам нужно просто иметь возможность считывать и сохранять этот атрибут и читать содержимое файла‐ссылки вместо содержимого того файла, куда она указывает. Замечу, что вас при этом вообще никак не интересует, куда указывает символическая ссылка.


Сохранения информации вида «этот файл имеет тот же inode, что и файл X за пределами архива» (т.е. сохранения «жёстких ссылок») от архиватора не ожидают и, наоборот, все сильно расстроятся, если архиватор будет это делать (поскольку это либо уязвимость, либо бесполезная информация, либо повреждение распакованного файла). Сохранять информацию вида «это тот же файл, что и файл Y в архиве» можно, распаковывать потом с использованием жёстких ссылок — тоже, но обычно никто не заморачивается, поскольку жёсткие ссылки используются сильно реже.

Причём, для NTFS 7zip ссылки криво-косо в одной из версий даже сохранял.
Единственное: пока — с 7-Zip можно работать лишь в командной строке, графического интерфейса нет

В чем новость-то? Что в линухе появился архиватор 7z с CLI?
man 7za — никак?

Некоторым программам лучше не развиваться интенсивно, иначе они превращаются в годзил.
Единственной функции которой мне нехватает в 7z так это что-то наподобие виртуального диска(не знаю как точно назвать), чтобы можно было запускать например инсталляторы не распаковывая все.

В Windows такое сделать практически никак. А на linux есть FUSE + loop mount.
Да, неправильно выразился. На Windows нет официального или общепринятого способа — только различной степени пригодности проекты. И как правило там какой-нибудь драйвер. Для себя использовать что-то можно, а вот встраивать в приложение я бы поостерёгся.

Сами Microsoft пилят ProjFS, но там свои особенности.
Они как правило предполагают использование дополнительного драйвера и потому сильно усложняют установку. Но да, они есть…

UPD: Я буду обновлять комментарии

Удалено. Надо обновлять комментарии прежде чем писать.

А зачем инсталляторы прятать в архив? Они сами по себе обычно пожаты.
Особенно забавляет когда архив с инсталлятором весит больше инсталлятора.

Часто инсталляторы состоят из кучи файлов. Даже если инсталлятор одним файлом, к нему иногда хочется приложить readme.txt или ещё что-то. Ну и ещё вариант — в архиве может быть много разных инсталляторов =)
winrar, например, сам по себе неплохой инсталлятор. И установить и шоткаты сделать и в реестр прописать можно.
запускать например инсталляторы

Не актуально, те 5 мегабайт для скачивания настоящего установщика из интернета смысла жать нет.
Инсталяторы, это пример, нам клиенты часто присылают макеты в архивах по несколько файлов, а то и десятков файлов. На самом деле довольно много сценариев, вплоть до редкоиспользуемой portable программы, которую держал бы в архие и раз в месяц запускал.

Подскажите удобный формат архивов для бекапов:


  • нужен индекс. tar.gz поэтому не подходит
  • неплохой уровень сжатия
  • метаинформация о файле (права), симлинки.
права относятся к файловой системе, а не к архиватору, симлинки тем более — это надо понимать где будет происходить распаковка, и подходит ли данная ОС под такие права.

Поэтому tar умеет максимум executable бит сохранить, а не права.
Так сохранять можно было бы уметь всё, а восстанавливать при распаковке только доступное в текущей ОС/ФС.

tar умеет хранить права, uid, gid и даже acl.

А как uid/gid сохранить между разными системами?
Вдобавок все равно, если распаковывать под рутом, то можно потом chmod, а если под юзером, то как он в принципе имеет право создавать файлы, принадлежащие другому uid?
Бессмысленная вещь.

Вдобавок gnu tar этого не умеет, а выяснять на каком отдельно взятом дистрибутиве чего, tar нестандартный…

tar (проверял именно gnu) сохраняет не только uid/gid, но и строковые user/group, которые между системами уже весьма неплохо переносятся

Можете показать ваш man tar об этом? Потому что как я вижу, gnu тар хранит только uid/gid
Просто при запаковке можно указать ему строковые имя пользователя, группы, но он их переведет в UID/GID текущей системы и сохранит именно числовые значения.

Во-первых, зачем мне man, когда я тупо смотрю созданный tar-архив через hex-редактор и вижу, что там записаны пользователь и группа в виде строк? А когда я распаковываю tar на другой системе, они прекрасно мапятся на локальные uid/gid (которые иногда отличаются) — я это активно использую на практике, хотя в ман даже ни разу не заглядывал.


Во-вторых, ну а если вы хотите всё-таки ман — вот вам ман:


https://www.gnu.org/software/tar/manual/html_chapter/Formats.html#Attributes


When writing an archive, tar writes the user ID and user name separately. If it can’t find a user name (because the user ID is not in ‘/etc/passwd’), then it does not write one. When restoring, it tries to look the name (if one was written) up in ‘/etc/passwd’. If it fails, then it uses the user ID stored in the archive instead.
То есть распаковывать нужно только от рута?

Во-первых, ну как бы да, а почему вы вообще ожидали, что tar каким-то волшебным образом обойдёт ядерные ограничения и сделает chown в обход штатных механизмов ограничения доступа?


Во-вторых, ну на самом деле если очень хочется, то можно — например, подключить какую-нибудь фейковую файловую систему (через FUSE например), которая не ограничивает chown, тогда tar успешно пропишет правильные uid/gid/user/group и без рута.

в том-то и дело, что смысл в хранении uid/username не особо нужен.

Ну почему же, для бэкапов. Когда распаковка от рута автоматически проставляет все нужные права (и даже acl) — это сильно облегчает жизнь при восстановлении из бэкапа.


Кроме того, в tar-архивах можно таскать целые образы ОС — в таком формате например Arch Linux ARM распространяется.

Это просто числа. Какому юзеру и группе они принадлежат на другой системе не имеет значения. Если у вас в системе nginx имеет uid 10, а в target системе 10 это cups, то распакованные файлы nginx будут принадлежать cups.


Или у вас вообще может не быть юзера с id 10.


В большинстве дистрибутивов (я не уверен, просто эмпирическое наблюдение) за такими известными юзерами зарезервированы одинаковые id.

А если я юзер user1 (uid 1000) и пытаюсь распаковать такой тар файл, в котором файлы были от юзера cups (10), при распаковке файлы будут кому принадлежать?

Или это новый внезапный способ сделать chown без root прав?

Не, распаковку с такими правами нужно производить от рута. Иначе можно было бы от юзера распаковать файл с suid например.
tar от юзера владельцем всех файлов сделает юзера.


Все упирается в то, что chown требует рута, даже если вы свой файл кому-то отдать хотите.

Есть pixz, он примерно как tar (поддерживается та же метаинформация) и xz (хорошее сжатие), но при этом ещё делает это параллельно (а не в один поток) и индексирует архив.
А теперь распакуйте один файл из 10Г под виндовз из без pixz. Или просто просмотрите список файлов без pixz.

А теперь распакуйте 7zip архив без 7zip. Не понимаю проблемы.

Собранный под Windows pixz я не нашёл за 5 минут поиска. Если его необходимо собирать из исходников — это сразу -99% потенциальных пользователей. Более того, я вообще впервые про него увидел в комментариях на этой странице, хотя десктопный Linux в том или ином объёме использую вот уже лет 8. Про bzip, gzip, xz, pigz слышал, а про pixz — нет.
7zip — первый же результат в поиске, к тому же он достаточно известный, чтоб свою страничку в Википедии иметь (тоже не самый надёжный источник, но от слабой паранойи от потенциально малварьно-рекламной ссылки в поиске поможет). И да, он уже собранный для Windows. Им просто удобнее воспользоваться.

Вы наверное веткой промахнулись и хотели мне ответить в другой. Потому что у автора комментария выше требование сохранять права, симлинки. Раз для бэкапов то еще и спец файлы пригодятся.

Нет, не промахнулся. Я именно хотел объяснить, что распаковать 7zip архив на Windows гораздо проще, чем pixz, с учётом необходимости установки самого архиватора.

Причем тут простота, если он не решает поставленную задачу?


Тут задача стоит траншею выкопать, а вы предлагаете автомобиль вместо экскаватора, потому что автомобиль водить проще и найти легче.

Вероятно, Sap_ru важно иметь возможность делать переносимые между платформами архивы, поэтому и была фраза «распакуйте один файл из 10Г под виндовз из без pixz» (ну нет pixz для Windows). 7zip вообще упомянули вы в ответе (что в рамках этой статьи нормально), но как будто его тоже нельзя на Windows открыть, в такой же мере, как и pixz. Это не так, на что я указал.

Как вы себе представляете переносимость прав между Windows и Linux?

Например, zip, rar, tar, tar+gzip/bzip2/xz, 7zip можно создать в Linux, а распаковать в Windows. Да, POSIX-права не сохранятся, но хотя бы дерево каталогов распакуете. С pixz всё не так однозначно
Подскажите удобный формат архивов для бекапов:
нужен индекс. tar.gz поэтому не подходит
неплохой уровень сжатия
метаинформация о файле (права), симлинки.

Юзеру нужны права. Он ищет альтернативу tar и gz. 7zip тут неприменим никаким образом.


Какой толк от такого бэкапа, если после его накатки система умрет?

А теперь распакуйте один файл из 10Г под виндовз из без pixz. Или просто просмотрите список файлов без pixz.
Юзеру нужны права, а также поддержка Windows, хотя бы для распаковки. Он ищет альтернативу tar и gz. pixz тут неприменим никаким образом.

Какой толк от такого бекапа, если его даже накатить не выйдет?

Я упоминания windows тут не вижу. Впрочем как и linux, но это хотя бы понятно из упоминания tar и прав.

pixz собирается на винде через msys2, достаточно стянуть PKGBUILD из арча и добавить префикс к пакетам. Просто никто собраный пакет не опубликовал в репозиторий msys.


Ну или WLS2 можно использовать.


Я уже потерял нить спора и куда-то не туда ушел.


Для обычного пользователя кроме 7zip ничего и не нужно. Для необычного пользователя выполнить make install не должно быть большой проблемой.

pixz собирается
мой первый комментарий был именно про это. Не про то, что его вообще невозможно никакими силами в мире заставить работать на Windows, а что его нужно собирать (или искать в не самых очевидных источниках), в отличие от 7zip.

pigz не содержит индекса

зато обратно совместим с gzip

Но он не решает задачу быстрого листинга файлов, которая требуется комментатору.

SquashFS. С любым сжатием на вкус. На Windows только пакуется относительно медленно (если много маленьких файлов, так под 400к).

О нет! Всё это время я пользовался пиратским 7зипом! Что же теперь делать?

В p7zip дико раздражает одна вещь: нет опции выставлять текущее время для распаковываемых файлов. Очень сильно не хватает этого.
В mint интегрирован удобный и надёжный менеджер архивов, который открывает и сжимает в кучу форматов в т.ч. и 7z.

Я как-то попробовал разные архиваторы и вышло, что надо юзать gzip. Что упаковал 15 лет назад, и сейчас хорошо достается на любые линуксы. А опыт взаимоотношений показал, что "отдавай zip и там справятся". Всегда помни, что стой стороны "домохозяйка" будет распаковывать. Так что лишние 7% сжатия отступают перед 93% популярности.


Однако 7zip я всегда использовал для себя. В частности, то что занимало место, но придержать ещё надо, а 7zip жмёт хорошо и быстро.

Так что лишние 7% сжатия отступают перед 93% популярности.

С другой стороны, если человеку на том конце очень нужно, то он установит архиватор. Например, я в облаке держу и шарю файлы. Для меня критичнее всего — занимаемое место (облако не резиновое), а если качающий не хочет установить / обновить свой архиватор, то он волен поискать другой источник (учитывая редкость контента — искать он будет долго и не факт, что найдёт).
Иногда соискатели присылают свои тестовые в 7z или даже RAR. Как думаете, а кому больше надо, чтобы я их посмотрел?

Если это соискатели на позиции разработчиков, то, очевидно, вам, как представителю работодателя.

Трудоустройство — это такая штука, которая должна быть взаимовыгодной :) Впрочем, каюсь, я и сам, если мне вдруг нечем открыть архив, прошу соискателя перепаковать его во что-то более распространённое. Соискателей много, а мой компьютер один, и чья-то любовь к малораспространённым архиваторам — явно не повод разводить у меня свалку всякого ненужного мне софта.
GUI-версии архиваторов обычно поддерживают ещё несколько наиболее популярных форматов, как минимум — на распаковку. Это что-то совсем экзотическое должно попасться.
Я уже столько лет пользуюсь p7zip, что удивлен, узнав, что это — неофициальная версия…
С другой стороны, именно архивы 7z делаю достаточно редко, чаще я p7zip использую, чтобы создать самый обычный zip, который отправляю вантузятникам (потому что стандартный tar.gz не все могут открыть, был удивлен, впервые узнав об этом лет 15 назад!).
А вот когда я вижу архив в RAR, то однозначно понимаю, что сделал его вантузятник, выходец из бывшего СССР (потому что этой проприетарщиной больше никто и не пользуется).
стандартный tar.gz
Это он у 1% стандартный.
Не 1%, а уже целых 5%!
И не всем же быть дятлами, как оставшиеся 95% населения!!!
Я вообще вантузоидов считаю некомпетентными. А уж если они еще и не хотят дела с линуксом иметь вообще ни в коем случае, то ненормальными.
Вам бы на opennet.ru с таким уровнем аргументации.
Его можно назвать «швейцарским ножом» в мире архиваторов.
Разве не Universal Extractor называют этим самым швейцарским ножом? Он конечно не умеет архивировать, но и 7-Zip всего в 4 умеет, а вот количество поддерживаемых форматов для разархивации у UniExtract какое-то просто запредельное, причём это не в стиле «9999 in 1», а всякие установщики, образы и даже видеоряды.
7-Zip — для наилучшего сжатия, UE — для чтения всего и вся.
Посмеялся от души от манеры повествования автора!
Ну все, осталось дождаться официального notepad++ на линукс
Интересно когда он войдёт в состав хотя бы Debian testing…
Хорошая новость. Еще один архиватор в Linux-е.
Лишь бы ушлые товарищи не пытались им архивировать бэкапы архивов — баз и огромных данных.Иначе, даже сгоревший датацентр не поможет.
пока — с 7-Zip можно работать лишь в командной строке, графического интерфейса нет. Возможно, его выпустят еще через пару десятков лет, кто знает.

Но зачем юзерам Линукса ГУЙ? Это ж вроде фишка такая у них — «элитарность» с использованием «чёрного экрана консоли», в отличие от нас, мастдаеводов.
P.S: ох, чую подгорит и минусов соберу.
P.S: ох, чую подгорит и минусов соберу.

Интересно, на что вы рассчитывали.
Странно, что-то ни на сайте, ни на sf не нашёл нигде исходников 7z 21.01
Там очень странная ситуация. Последние открытые исходники имеют дату два года назад.
Версии 21.01 действительно нигде. Более того, несколько изменилось поведение автора с версии 19 — он полностью перестал выкладывать исходные тексты. Получается, что 7z 21.01 это вообще непонятно что за версия и кем выпущена!
Автора неоднократно просили показать исходники или показать репозиторий, но просто игнорирует такие вопросы.
Возможно, есть основания подозревать нехорошее.
Связался с автором 7z. Он сообщил, что исходники будут выложены через несколько недель.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.