[samba] thunar vs mc

mc не проигрывает видео. Он запускает внешний проигрыватель в зависимости от настроек в /etc/mc/mc.ext или ~/mc/bindings

Долгое время запуска проигрывания видео через SMB-соединение происходит из-за того, что это видео сначала скачивается в /tmp/mc-<user>, а потом только запускается видеопроигрыватель. Пока что нет способа «ускорить» произведение. Разве что смонтировать SMB-ресурс :)

mc сначала скачивает файл, потом его проигрывает

копай в эту сторону

Можно ли научить mc монтировать ресурсы самбы при заходе на них? Или как-то делать это автоматически для всего, что видно по avahi.

btw, а есть способ заставить mc не сохранять файл предварительно, а сразу пайпить в нужную команду?

Пока такого способа нет.

> Можно ли научить mc монтировать ресурсы самбы при заходе на них? Или как-то делать это автоматически для всего, что видно по avahi.

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

Жалко, что это не реализовали. mc даже при передаче файла по sshfs вместо того, чтобы запустить scp, сначала сохраняет файл во временную директорию.

если копировать с удаленной машины на локальную - все нормально. лагает только если с локальной на удаленную заливать

а будет?

Я об этом узнал, когда у меня место в /tmp (который в оперативке) кончилось при копировании фильма. Пришлось через fuse монтировать.

Цитируем Spectator

Можно ли научить mc монтировать ресурсы самбы при заходе на них?

autofs, smbnetfs — сотни их

Сам юзаю smbnetfs (потому что она на fuse, если локалка отвалится, то можно просто процесс прибить для размонтирования директории. С autofs такие фокусы не работают)

С именованной пайпой есть одна существенная трабла: невозможно seek'кать по потоку. Было бы просто здорово, если бы можно было бы через, например, ioctl() указать свой каллбэк для сикания пайпы передающей стороной.

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

Избавление от темпов - это один из план работ. Ещё разрабатывается новый VFS-модуль SFTP, который будет лишён этого недостатка.

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

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

а зачем именованные пайпы и сикать? я имел в виду - прописывать в mc.ext нечто типа cmd '%<f', что бы означало сразу передавать содержимое %f на вход cmd, минуя временные файлы

Как раз в идеале было бы монтировать через fuse куда-нибудь во временную директорию, а при выполнении команды в отдаленной директории, вызывать ssh <команда>.

> я имел в виду - прописывать в mc.ext нечто типа cmd '%<f', что бы означало сразу передавать содержимое %f на вход cmd, минуя временные файлы

вместо %f подставится /#sh:/user@host/path/file.ext
получится

cmd '</#sh:/user@host/path/file.ext'

шелл отругается на неправильный путь.

сейчас да, это я уже понял.

но реализовать подобные подстановки в будущем, чтобы в результате была некая конструкция типа «mccut /#sh:/user@host/path/file.ext | cmd» было бы здорово

Интересная мысль.

Как раз в идеале было бы монтировать через fuse

Дык не линуксом единым...

> в идеале было бы монтировать через fuse куда-нибудь во временную директорию

в идеале нужно нормально задействовать gio/gvfs.

кстати, seek'ать с перенаправлением вывода всё также нельзя будет, как и с именованными каналами... :(