локальный сервер файловых операций

это пахнет systemd и поэтому ненужно

иначе говоря, такой аналог прогрессбаров копирования в области нотификаций, но уровнем пониже, чем DE.

не помню уже, на кой мне это нужно было, и какие тут плюсы. прошу объяснить)

Тю, прогрессбары. Вон в HAMMER2 таким макаром будет реализована мультимастерная кластерная ФС

могу только предположить, что запах systemd въелся в тебя

нее, не может быть, я его издалека только видел пару раз :)

Ну и стоит ли говорить, что там демон завязан на некоторой функциональности из ядра, а не на cp/mv/rm

Außerdem, в plan9 это вроде обычное дело

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

То есть смысл этого всего - это только возможность мониторинга другими процессами? А что тогда используют для этого DE типа гнума или KDE?

У меня в зависимостях один раз потянулось это: http://en.wikipedia.org/wiki/GnomeVFS

Но я испугался и не стал ставить

тогда, вероятно, тебя преследует его образ)

А что тогда используют для этого DE типа гнума или KDE

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

тут - наоборот, область нотификации запрашивает данные у (единственного) копирующего сервера.

бонус в том, что сервер может оптимизировать порядок копирования, так как все операции проходят через него.

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

GnomeVFS

вангую, это виртуальная фс, где в качестве корня выступает «мой компьютер», в нем папки С:^W Home, Root, sd_flash ...

Ага, а ещё там прикручена самба, nfs и всякая фигня. Умеет ли оно оповещение по твоему сценарию - я хз

нет ли варианта использовать нечто подобное для vifm?

В данный момент можно отправлять background-операции из командной строки как remote-команды и смотреть на список задач в :jobs (визуализация прогреса всё ещё крайне ограниченая). Если без шела, то достаточно добавлять & к командам. Конкретно переделывать все операции на такой лад - почти проблема, так как изначально закладывалась синхронность таких операций.

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

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

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

я такое в институте писал .. троянец называется :D

Я думаю тут хватит обычного LD_PRELOAD

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

можно конкретнее? любая асинхронность лучше, чем абсолютно несинхронизируемые действия в одной фс, как это по-дефолту сейчас(например, два mv одного и того же каталога в разные места, параллельно)

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

прямой выгоды от её реализации я в данный момент не вижу

собственно, реализация в vifm не требуется - основная часть работы - это реализация библиотеки, которую vifm будет использовать. выгода - прилагаемый индикатор прогресса и бекграундинг через юникс-вей. например отобразить интерфейс управления бекграундными операциями можно запустив консольный клиент-«нотификатор»

хватит alias mv=myprog mv, alias cp=...

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

еще один плюс, гнушные утилиты могут играть роль бекенда для всей этой конструкции, тем самым, скажем, команда :cp автоматически будет поддерживать все опции гнутой cp (ну не все, а те, которые не мешают отображению прогресса. например, --copy-contents, но не -R, которую придется реализовать ручками)

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

Я имел в виду немного другую ситуацию: если последовательно переместить директорию, а потом в ней же попробовать что-то сделать, то ничего не выйдет, так как её после первого действия уже не существует; если делать то же самое с асинхронностью выйдет два варианта:

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

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

собственно, реализация в vifm не требуется - основная часть работы - это реализация библиотеки, которую vifm будет использовать. выгода - прилагаемый индикатор прогресса и бекграундинг через юникс-вей. например отобразить интерфейс управления бекграундными операциями можно запустив консольный клиент-«нотификатор»

Я имел в виду реализацию в общем как библиотеки так и любой программы, которая бы её использовала. Кстати, приложения для использования такой библиотеки надо значительно менять. Модель обработки уведомлений слишком разнится со схемой выполнения синхронных операций. Просто подменить вызовы соответствующих функций не выйдет, иначе произойдёт рассинхронизация представления о состоянии ФС в приложении и по факту. Например, для записи операции в список отмены, надо дождаться завершения операции. Или если надо выполнять ряд связанных операций, надо ждать каждую, чтобы потом начать следующую. Чтобы это как-то упростить придётся добавить ожидание операций и по умолчанию обрабатывать их как синхронные.

Нечто подобное (асинхронное) имеет место быть на офтопике восьмой версии, где синхронных вызовов просто нет для приложений определённого типа. Чтобы с этим хоть как-то можно было работать, приходилось вставлять wait() после каждой операции. Я боюсь, как бы не каждая попытка внедрения глобальной асинхронности обречена на такую участь вырождения в псевдо-синхронный код. ИМХО, единственное, что может тут спасти, так это правильный выбор того, что должно быть асинхронным, т.е. если сделать что-то крупное асинхронно, то это намного удобнее, вот только в таком виде это больше похоже на потоки.

Для меня в файловых операциях важна возможность последовательного выполнения. Это замечательным образом реализовано в файл-менеджере spacefm - как очередь заданий. На 100% процентов удовлетворяет мою потребность в «сервере операций»

Также, можно ставить операции на паузу, мониторить прогресс, есть notifications.

кто сказал «pv»?

покажи, как с помощью pv без дикого оверхеда отобразить прогресс, скажем, копирования каталога

если последовательно переместить директорию, а потом в ней же попробовать что-то сделать

так и сейчас такое возможно. что мешает пользователю начать одновременно перемещать директорию в dolphin и параллельно делать что-то в этой директории из консоли или из того же dolphin? сервер как раз сможет взять на себя контроль таких вещей (но совсем не обязан) и запретить операции над уже используемым объектом

если в vifm сделать бекграундинг, то и его это же коснется

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

никто не заставляет менять сразу все приложения. если будет такая библиотека с cli, юзер сможет сделать алиасы типа alias mv=ngu mv, а разработчики постепенно, при желании, начинать использовать готовую библиотеку вместо велосипедирования.

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

Я боюсь, как бы не каждая попытка внедрения глобальной асинхронности обречена на такую участь вырождения в псевдо-синхронный код

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

ну и в вынесении общего кода большого количества приложений в одно место

кроме того, управление приоритетами можно при желании будет автоматизировать. т.е. чтобы реализовать вот это:

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

не нужно будет раздувать код сервера, можно просто заскриптовать нужную логику башем.

так и сейчас такое возможно.

Я и не говорил, что невозможно. Только сказал, что асинхронность значительно облегчает это.

если в vifm сделать бекграундинг, то и его это же коснется

Он и так есть для файловых операций в командной строке (хотя и не для всех).

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

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

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

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

покажи плз, как отобразить прогресс копирования папки с помощью pv. а потом я тебе объясню, в чем разница между оверхедом твоего решения и «оверхедом» прогрессбара.

я мог бы на питоне сделать прототип. На си - это мне не по зубам будет.

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

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

хотя вот, нашел линк на ветку обсуждения:

vifm обновился до версии 0.7.6 (комментарий)

я мог бы на питоне сделать прототип. На си - это мне не по зубам будет.

Если ли б был, то я бы глянул.

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

Этот сервер называется ядро.

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

большинство файловых менеджеров так и делают. редкие исключения - vifm (я про команды p y d D ...) и гнушные утилиты.

недавно, интересуясь, насколько гладко можно перенести консольный ui на новую систему, спрашивал: дополнительные действия при форке программы в шелле

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

согласен, наверное

прототип

к концу января попробую что-нибудь сообразить. стучался как-то в джаббер в профиле, он неактуален?

стучался как-то в джаббер в профиле, он неактуален?

Я в него не захожу (кстати, не уверен, что даже пароль помню), наверное, лучше его убрать из профиля. Надёжнее на почту, её я проверяю.