Comments 77
Моя главная боль это не дай макаронному монстру подключить сетевой диск, который потом окажется отключенным. Теперь любые операции с вызовом системного окна сохранения файла будут сопровождаться тормозами, ведь windows этот путь еще и бережно добавить в папку Быстрого доступа. Эту проблему так и не решили даже в win11.
Вторая проблема с тормозами это попытка Explorer определить содержимое (мета данные) медиа файлов, и если, имея неосторожность, откроешь случайно папку, содержащую медиа файлы без метаданных, Explorer их все равно будет сканировать и он сам в это время зависнет.
А ещё если открыть папку с кучей весьма объёмных инсталяшек, то проводник будет в каждом файле искать его значок, а антивирус при этом кинется проверять каждый файл. А если это всё на сетевом диске, и канал не очень быстрый... Короче, просто открыть и посмотреть содержимое такого диска может надолго подвесить систему.
У меня так подвисает Explorer минут на 20 на рабочем буке с касперским и интсаллером Intellij Idea.
Отличная причина использовать тотал или фар и, если тотал, то отключать всякие весёленькие ненужноиконки, хотя бы на внешних носителях
Ещё могу добавить про безобразную работу десятки с дискетами. По работе приходится перекидывать файлы с измерительного прибора через дискету. Как известно, дискета - очень капризный носитель, особенно позднего выпуска, особенно те, что остались сейчас (им уже немало лет). Поэтому чем меньше её пилить головкой флопаря операциями чтения-записи, тем лучше. На WinXP система дискету вообще не трогает пока к ней не обратишься, и при обращении, считав перечень файлов и папок, дискетник замолкает. А на десятке идут самопроизвольные обращения к дискете, а при заходе на неё система настойчиво считывает какие-то метаданные файлов, строит эскизы картинок, и прочее и прочее. Эмпирически, дискета пилится втрое активнее, чем на XP или Win9x. И сдохнет раньше.
Пора уже на эмуляторы переходить https://en.m.wikipedia.org/wiki/Floppy_disk_hardware_emulator
Там в приборе slim-флопик, и неизвестно какая распиновка. Теоретически, конечно, можно заморочиться и подключить туда эмулятор, но этот прибор не очень часто нужен, и мне за это не заплатят. Ещё и скажут, мол, испортил прибор, он теперь поверку не пройдёт. Так что пока пользуюсь как есть, по мере надобности вырабатывая старые запасы дискет.
Ещё и сачковать можно на законных основаниях.
— Почему сидим, не работаем?
— Жду, пока дискета отформатируется!
Папа, а правда, что Windows - многозадачная система?
Да, сынок, сейчас дискету доформатирую и покажу.
Это заговор против флоппи-дисков
Могу добавить от себя: бывает, что открыты два окна Проводника, из левого дрэг-энд-дропом кидаешь файлик в правое, и если в правом окне, в левой его части, в дереве проводника, курсор мышки с файлом хоть на долю секунды зайдёт на иконку недоступного сетевого диска - ещё не дав донести файл до пустой области открытой папки в правом окне, винда тут же выкинет поверх всего окно, сбив фокус ввода, мол, данный диск недоступен. И тогда нужно бережно вернуть файлы обратно, а иначе можно и потерять данные. Это поведение ещё хуже, чем когда присутствует дребезг контакта в микрике левой клавиши мыши, когда тоже можно сбросить файлы не туда. Причём это зависит от каких-то фаз Луны: порой при наведении перетаскиваемого файла на недоступный диск курсор просто показывает значок недоступности и окошко не выкидывает.
Вдобавок, у меня на 10 при правом клике по любому элементу (папке/файлу) в проводнике делается одно слышимое обращение к дискете, видимо, для отрисовки списка дисков (в т.ч. дискеты) в меню "Send to"
Хорошо, если сразу выкидывает. У меня на рабочем компе секунд на пятнадцать эксплорер просто намертво встаёт колом и ч довольно часто на эти грабли наступаю, хотя в основном far manager использую.
По умолчанию ведь винда копирует а не перемещает, если кидаешь на другой диск. Файлы точно теряются? Может в дерево проводника падают куда-нибудь?
открыты два окна Проводника, из левого дрэг-энд-дропом кидаешь файлик в правое
Коллеги, расскажите товарищу кто-нибудь про волшебные комбинации Ctrl-C / Ctrl-V, а то он так дотаскается когда-нибудь...
Забавно, но у меня бы такая операция была бы из правого окна в левое. Психологически слева у меня всегда destination, а справа source.
Не совсем равнозначная замена. Я использую drag-n-drop специально, чтобы не затирать буфер обмена.
В винде по win+v — всплывет буфер обмена с историей. Не благодарите :)
Там будет только текст, файлов не будет. Бонусом — копирование файлов через RDP не всегда любит, когда что-то ещё попадает в буфер и прекращается после такого.
Таскать файлы мышкой — через RDP? О-о-о-о, месье тонкий извращенец!
Не пойдёт. Я по работе делаю в Word фотоотчёт на несколько тысяч фотографий, и у меня всё оптимизировано: кинул мышкой фотку - она встала в ячейку таблицы и смасштабировалась. Тем же методом раскидываю фотки из общей кучи в десятки заранее подготовленных папок. С клавиатуры это будет дольше и неудобнее.
Все это редактировалось ещё в win 98 c помощью твикеров, где-то в глубине реестра есть настройки для всего этого. С тех пор этот твикер попал в неблагонадёжные, и я его больше не использую. Назывался как, уже не помню.
7-zip так и не научился открывать зипы из макоси... вечно какие-то глюки.
А на макоси вы файлы жали 7-zip'ом или каким-нибудь нескучным весёленьким архиватором, который собрал все грабли исторически заложенные в zip, начиная с кодировок?
Обычно на маке жмут либо встроенным компрессором, либо через keka. Да и не припомню каких-то проблем
Из того, что я помню как получатель этих архивов, сломанная кириллица в именах файлов плюс всякие .DS_Store в них.
Сломанная кириллица — это и есть уже упомянутые проблемы с кодировкой, а "всякие .DS_Store" почему вообще записаны в проблемы?
Сломанная кириллица
Маки не умеют в юникод? О_о
Впрочем, если и так, то это явно на стороне мака проблема.
Ubuntu 18.04:
zip --version
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
Currently maintained by E. Gordon. Please send bug reports to
the authors using the web page at www.info-zip.org; see README for details.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip,
as of above date; see http://www.info-zip.org/ for other sites.
Compiled with gcc 6.3.0 20170415 for Unix (Linux ELF).
Zip special compilation options:
USE_EF_UT_TIME (store Universal Time)
BZIP2_SUPPORT (bzip2 library version 1.0.6, 6-Sept-2010)
bzip2 code and library copyright (c) Julian R Seward
(See the bzip2 license for terms of use)
SYMLINK_SUPPORT (symbolic links supported)
LARGE_FILE_SUPPORT (can read and write large files on file system)
ZIP64_SUPPORT (use Zip64 to store large files in archives)
UNICODE_SUPPORT (store and read UTF-8 Unicode paths)
STORE_UNIX_UIDs_GIDs (store UID/GID sizes/values using new extra field)
UIDGID_NOT_16BIT (old Unix 16-bit UID/GID extra field not used)
[encryption, version 2.91 of 05 Jan 2007] (modified for Zip 3)
Encryption notice:
The encryption code of this program is not copyrighted and is
put in the public domain. It was originally written in Europe
and, to the best of our knowledge, can be freely distributed
in both source and object forms from any country, including
the USA under License Exception TSU of the U.S. Export
Administration Regulations (section 740.13(e)) of 6 June 2002.
Zip environment options:
ZIP: [none]
ZIPOPT: [none]
macOS 13:
zip --version
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
This is Zip 3.0 (July 5th 2008), by Info-ZIP.
Currently maintained by E. Gordon. Please send bug reports to
the authors using the web page at www.info-zip.org; see README for details.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip,
as of above date; see http://www.info-zip.org/ for other sites.
Compiled with gcc Apple LLVM 14.0.0 (clang-1400.0.29.2) [+internal-os, ptrauth-isa=deployment-target-based] for Unix (Mac OS X) on Nov 4 2022.
Zip special compilation options:
USE_EF_UT_TIME (store Universal Time)
SYMLINK_SUPPORT (symbolic links supported)
LARGE_FILE_SUPPORT (can read and write large files on file system)
ZIP64_SUPPORT (use Zip64 to store large files in archives)
STORE_UNIX_UIDs_GIDs (store UID/GID sizes/values using new extra field)
UIDGID_16BIT (old Unix 16-bit UID/GID extra field also used)
[encryption, version 2.91 of 05 Jan 2007] (modified for Zip 3)
Encryption notice:
The encryption code of this program is not copyrighted and is
put in the public domain. It was originally written in Europe
and, to the best of our knowledge, can be freely distributed
in both source and object forms from any country, including
the USA under License Exception TSU of the U.S. Export
Administration Regulations (section 740.13(e)) of 6 June 2002.
Zip environment options:
ZIP: [none]
ZIPOPT: [none]
Нет UNICODE_SUPPORT.
А зачем эти дс_сторе пихать в архив?
Я первый раз узнал про DS_Store когда собрал архив доков для теста, закинул на авс в наш обработчик и получил ошибку что файлик внутри архива не мог обработаться и выкинул ошибку. Но я же сам паковал архив-весело дебажил это дело и искал проблему.
стандартным
Вот, сабжик скоро 10 лет отметит, а воз и ныне там, 7z рулит
https://ru-linux.livejournal.com/2883307.html
а вот ещё более старая статья про кракозябры, в т.ч. в комментариях народ делится теми же новостями про устаревшие спеки zip
У меня есть большие запароленные rar-архивы с личными документами, с 7% информации для восстановления, некоторые solid, созданные мною в WinRAR. Он их открывает нормально, а вот 7zip не может, тупит.
А вот претензия к зипам — это уже другое дело. Но 7-zip в этом плане менее «всеядный», чем некоторые другие архиваторы, да. Например, если в именах файла zip использовать обратный слеш вместо прямого, который должен быть там по спецификации, 7-zip не понимает, что это разделитель имён папок.
Ссылки на багрепорт почему-то нет: https://sourceforge.net/p/sevenzip/bugs/2371/
Там более, что тут есть прямо причина тормозов - может быть её следовало бы добавить и там?
Что есть, то есть (ну, точнее - того нет).
После отсутствия вообще какой-либо реакции в саппорте, я и решил разобраться в вопросе сам. Насчет уточнений вы правы. И раз так случилось, что Игорь Викторович наш соотечественник, думаю можно оставить там ссылку на эту заметку. Я честно говоря, просто успел забыть про тикет, да и про саму заметку. Кто ж знал, что на модерации она почти три недели провисит в песочнице...
Я так и не понял, в чем именно проблема. В том, что 7zip циклом проходится по всем файлам, когда как совестные разработчики ограничиваются 16-ю файлами?
Ну "интрига с садовником" в общем-то раскрыта в начале заметки (в сноске о проводнике Windows). Если мы посмотрим Рекомендации по обработчикам контекстного меню от MS, то там явно прописан оптимальный алгоритм. А учитывая тот адок, который начинается при вызове меню, можно понять и столь малое значение (так-то по факту можно и для 64 объектов обработку делать и даже больше, без ощутимого лага). На алтарь универсальности методов MS принесли производительность, плюс тонна легаси и желание навернуть модных "свистелок" вместо оптимальной реорганизации кода.
По такому алгоритму работает и штатный проводник, независимо от количества выбранных файлов, он останавливает итерацию после первых 16 объектов и создает меню. 7-zip в свою очередь, просто в лоб парсит все содержимое объекта данных, сколько бы тысяч "имён" там ни было, а это не самая быстрая операция, знаете ли... И если так случилось (а это почти всегда так и бывает), что программа не ограничила число файлов для которого вызывает меню, то она сама потратила лишнее время на генерацию PIDL, а тут еще и архиватор, ничего не проверяя, начинает лопатить всё подряд. Так и живём...
Тогда я не понимаю, почему тупит на одном выделенном файле.
У вас лаг в меню на одном файле? Такого обычно быть не должно (ну может какое-то совсем кривое расширение шалит).
А если вы про момент в заметке, где проверяется один файл, то это просто абстрактная "точка отсчета", никаких тормозов там нет, но поскольку нашелся лишний пример "плохого" кода в расширениях, я об этом упомянул и отметил, что это "не те дройды", те не тот код, который дает основную задержку появления меню.
А что вы хотите сделать, что вынуждены выделять много файлов?
Для упаковки папки - проще выделить папку уровнем выше и это будет условно бесплатно.
На файлах порядка 10шт тормозов тоже нет.
Я уверен, что есть достаточно кейсов когда в работе находится ощутимо большое количество файлов. В этом подмножестве будут и случаи, когда нужно выделить файлы выборочно, тогда их нужно дополнительно выпиливать из архива?
А если другой пользователь не догадается поступить подобным образом?
А когда в новом апдейте меню еще "притормозят" нужно будет прикладывать к монитору подорожник?
В общем я не из любителей делать вид, что граблей не существует и искать хитрые методы не наступать на них. С подобным подходом легко не заметить, что "ствол уже направлен в ногу"... Есть очевидная проблема, затрагивающая ощутимую часть нашей сферы деятельности, и ее надо решать. Вот так все просто.
Я согласен, тормозит - плохо, пропускать такое нельзя.
Но я 7zip-ом пользуюсь лет 10 и ни разу не столкнулся с такой проблемой. Мне не приходится видимо выполнять такие операции. Поэтому и сомнения вызвал кейс.
Впрочем, у меня и выделение одного файла не тормозит, ну или очень быстро отрабатаывает диск, лень профилировать.
Мб вы просто используете штатный проводник, а не какой-то другой ФМ?
Как это ни странно, но я сам пользуюсь 7-zip уже более 10 лет и просто уже привык к этим микро-тормозам и "неторопливому" меню. Если на этом не фокусировать внимание, вроде все достаточно быстро работает и мысли не было что-то проверять. Но вот как раз такие пограничные случаи и выявляют всю кривизну рабочего окружения, когда копнешь чуть глубже...
PS
Про выделение одного файла см выше.
Хммм... а я-то думал, это Far EMenu тормозит, тоже привык - если надо слишком много файлов обработать по контекстному меню на медленной машине (ну очень-очень редко, но такое бывает), делал через проводник, и как-то не задумывался о причинах...
К сожалению даже самый свежий билд Far (как и все файловые менеджеры что я тестировал) тоже ничего не проверяет и хоть и отрисовывает "окно" сам, базовый алгоритм создающий пункты для меню у него стандартный. Я в общем-то и написал данную заметку с целью "подсветить" проблему и думаю имеет смысл просто сделать тикет на гитхабе фара, благо он до сих пор активно допиливается.
намедни сжимал папку с 500 000 вирусных скриптов. видимо только для отображения прогресс-бара 7zip молотил по ней до начала сжатия полчаса. я-то привык, но может кто скажет Павлову, что так делать не стоит?
Кто-то выложит патч?
Магия Хабра сделала свое дело (ну или детализация причин проблемы, кому как удобнее), тикет переведен в статус open-accepted и разработчик "хотя бы частично" исправит сабж.
Можно про "первый подвернувшийся профайлер" поподробнее?
Напомнило квадратичную сортировку иконок рабочего стола.
habr.com/ru/company/vdsina/blog/544218
Будет ли та же проблема в 11 винде, если ты не вызываешь старое меню? Там как раз эта часть с кастомными пунктами меню переделана
Ну и убирайте всё неиспользуемое из меню (ShellExView в помощь).
Это если софт вам позволит (не шучу).
Например клиент облака Mail.ru (не «Диск-О», а который был до него) при каждом запуске регистрирует своё расширение Проводника, если обнаруживает, что оно отсутствует в контекстнеом меню. А на случай, если пользователь шибко умный и захочет dll-ку расширения стереть, чтобы её нельзя было перерегистрировать, это мейлрушное поделие хранит dll-ку непосредственно внутри своего исполняемого файла и распаковывает в %TEMP% при запуске.
Победить удалось лишь отреверсив приложение и влепив возврат в начало функции, которая занимается распаковкой и регистрацией всего этого дерьма.
Напишите автору на форуме.
Как я понял ошибка исправлена в сегодняшней бета версии 7-Zip / Discussion / Open Discussion: 7-Zip 23.00 (sourceforge.net) Тестируйте
7-zip — нет времени спешить