LINUX.ORG.RU

Баг MC


0

1

Есть один не приятный баг в MC с zip архивами.
Суть такова:
Берем зип архив 1.zip копируем его в 2.zip, открываем через mc 2.zip удаляем/добавляем файлы в архив, копируем 2.zip в 1.zip заходим из MC в 1.zip и видим что он не изменился.
Я так понимаю что где то кешируется содержимое архива.
Вопроса: это баг mc, баг unzip? И как это можно побороть?


В эту тему при помощи чёрной магии призывается Slavaz!

Deleted
()

«Черная магия»? Некромансия? Вот спасибо :)

По проблеме: это... гм... ну не то, чтобы баг. Это таймаут высвобождения vfs. Таймаут нужен для того, чтобы содержимое каталогов на, например, ftp или fish не перечитывалось при каждом входе или выходе. И этот же таймаут действует и на extfs (которая в том числе заведует работой с архивами).

Уменьшить таймаут здесь:
F9 -> Настройки -> Виртуальные ФС... -> Тайм-аут высвобождения ВФС:
Поставьте там 1

В планах сделать возможность персональных настроек для каждого VFS-модуля, но сейчас этот таймаут один для всех модулей.

Slavaz ★★★★★
()
Ответ на: комментарий от Slavaz

А проверять время модифицирования и отсуствие записи?

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

Не?

ChALkeR ★★★★★
()
Ответ на: комментарий от imul

> Ты предлагаешь в mc запоминать время модификации для всех файлов во всех файловых системах?

зачем на всех? только на тех, которые он закешировал

anonymous
()
Ответ на: комментарий от imul

То есть завести для архива хренов кэш — это нормально и места не жрёт, а вот добавить к хренову кэшу 64 бит времени модификации файла — тут-то и пойдут тормоза и память улетит?

ChALkeR ★★★★★
()
Ответ на: комментарий от ChALkeR

> То есть завести для архива хренов кэш — это нормально и места не жрёт, а вот добавить к хренову кэшу 64 бит времени модификации файла — тут-то и пойдут тормоза и память улетит?

два чаю этому господину!

anonymous
()
Ответ на: комментарий от anonymous

> зачем на всех? только на тех, которые он закешировал

И как это решит проблему с переименованием архивов?

imul ★★★★★
()
Ответ на: комментарий от ChALkeR

В любом случае это проблема не mc, а vfs.

imul ★★★★★
()
Ответ на: комментарий от imul

>> зачем на всех? только на тех, которые он закешировал

И как это решит проблему с переименованием архивов?

Если сохранённая дата модификации отличается от даты архива 1.zip (такое будет при повторном заходе), то старый кэш удалять и создавать новый с предупреждением «Удалённая версия архива изменена. Принять изменения или оставить локальную копию?». Как-то так должно работать.

backbone ★★★★★
()
Ответ на: комментарий от backbone

> Если сохранённая дата модификации отличается от даты архива 1.zip (такое будет при повторном заходе), то старый кэш удалять и создавать новый

именно

с предупреждением «Удалённая версия архива изменена. Принять изменения или оставить локальную копию?». Как-то так должно работать.


не понял, что за «удаленная» версия? не надо никаких пердупреждений, элемент в кеше, отвечающий за vfs, построенную на начальном архиве, - это внутренняя сущность программы, т.е. юзеру вообще не полагается о ней ничего знать; конечно, ему может понадобиться копия только что перезаписанного (причем, своими прямыми осмысленными действиями, а не какими-то неявными автоматическими действиями программы) архива, но ведь mc - это не средство защиты данных от идиотских действий пользователя :)

anonymous
()
Ответ на: комментарий от backbone

Ладно, как это поможет, если переименование архива произошло не в mc? Может лучше на *notify ядерный для элементов vfs вешаться? Мимо него уж точно ничего не пройдёт.

imul ★★★★★
()
Ответ на: комментарий от imul

В случае привязки к inode файла, в ситуации ТС mc считал бы 1.zip до эксперимента и 1.zip после него разными файлами. Всего делов-то.
Не вижу здесь никакой зауми и костылей, вполне обычная работа с inode'ами ФС. Не везде они, правда, есть. Кстати, на NTFS есть его аналог - object id.

blexey ★★★★★
()
Ответ на: комментарий от anonymous

> не понял, что за «удаленная» версия? не надо никаких пердупреждений <...>

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

backbone ★★★★★
()
Ответ на: комментарий от imul

> Ладно, как это поможет, если переименование архива произошло не в mc?

Ну так дата архива изменится. И mc будет «знать», что локальный кэш не соответствует содержимому архива в общем случае.

> Может лучше на *notify ядерный для элементов vfs вешаться? Мимо него уж точно ничего не пройдёт.

Что-то подсказывает, что это есть правильный путь. :)

backbone ★★★★★
()
Ответ на: комментарий от blexey

Несовместимо с онлайн-дефрагментаторами в принципе. Несовместимо с рейзером. Я ещё могу обосновать для себя, когда костыль нужно пихать для какой-то операционной системы, но для каждой файловой имхо перебор.

imul ★★★★★
()
Ответ на: комментарий от imul

Ладно, убедил. Варианты с датами кэша/файла или ядерным *notify выглядят лучше.

blexey ★★★★★
()
Ответ на: комментарий от sudo-s

Мне одному стало интересно для чего ТС сидел и пихал архив в архив?

я часто создаю архив командой:
$ tar -czf ../archive_name.tgz ./*
а потом через mc захожу в архив, чтобы посмотреть, что все правильно там создалось, и иногда бывает, что неправильно (например, забыл какой-то файл), и приходится пересоздавать архив, предварительно что-то изменив, но с тем же именем; повторный заход в архив через mc не показывает никаких изменений - ругаюсь и изменяю имя архива;
а ведь достаточно всего лишь при идентификации принадлежности элемента кеша к конкретному архиву использовать не только имя файла, но и дату его модификации; тогда новый архив уже не зацепит старый кеш, и создаст новую vfs, а старый файл пусть стухнет по таймауту; это же все настолько элементарно и естественно, что непонятно, почему не сделано изначально

anonymous
()
Ответ на: комментарий от sudo-s

У меня часто бывает что собираю архивы maven'om/ant'om а изменений не вижу.

n4ela
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.