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

> далеко не все архивы позволяют такой финт

да. для "тупых" в таком отношении архивов придётся распаковывать в /tmp, но это дико медленно...

>> totalcmd использует библиотеку Unrar от автора архиватора

> осталось найти исходники библиотеки unrar от автора архиватора.

Формат открыт, да к тому же unrar-free тоже есть. Так что сорсы имеются.

[root@onestep-box openssl]# pacman -Qi kdelibs | grep Depends
Depends On : arts db libxslt pcre libart-lgpl openexr avahi jasper

Ну совсем никто не пользуется. ;)

>Я думаю, что и сабж без гнома вряд ли будет функционален.

зря думаешь. Потому что будет - для этого и выносят =)

>да. для "тупых" в таком отношении архивов придётся распаковывать в /tmp, но это дико медленно...

Вот-вот. Прозрачность оборачивается тормозами

>Формат открыт, да к тому же unrar-free тоже есть. Так что сорсы имеются.

unrar-free на некоторых архивах наворачивается почему-то

Т.е. он не потребует glib и gtk?

>> да. для "тупых" в таком отношении архивов придётся распаковывать в /tmp, но это дико медленно...

> Вот-вот. Прозрачность оборачивается тормозами

Пардон, а Вы знаете, как это сделать непрозрачно и быстро для "тупых" архивов?

>>Формат открыт, да к тому же unrar-free тоже есть. Так что сорсы имеются.

>unrar-free на некоторых архивах наворачивается почему-то

go to bugzilla.

>Я не видел, чтобы это было реализовано. Но, например, в siefs(fuse-фс для диска мобильника) в параметрах задаётся расположение сериал-порта и скорость работы. Не вижу принципиальных отличий от логина/пароля.

это параметры _монтирования_ fuse. до того как дернется fuse - вызов open пройдет через ядро

задача: передать в имени файла архива пароль на архив, путь к файлу внутри архива и кодировку имен файлов в архиве. Ах да, ещё тип архива надо в этом передать. Все через open(), чтобы не ломать посигз =)

>Пардон, а Вы знаете, как это сделать непрозрачно и быстро для "тупых" архивов?

непрозрачно и быстро? tar -xvf

>go to bugzilla.

лень :)

>Т.е. он не потребует glib и gtk?

glib только

кстати и glib и gtk - вполне себе независымые от гнома библиотеки.

у меня kdelibs не зависит от openexr,avahi,jasper, собрать без arts вроде тоже можно

>> Я не видел, чтобы это было реализовано. Но, например, в siefs(fuse-фс для диска мобильника) в параметрах задаётся расположение сериал-порта и скорость работы. Не вижу принципиальных отличий от логина/пароля.

> это параметры _монтирования_ fuse. до того как дернется fuse - вызов open пройдет через ядро

Не понимаю. Мы монтируем файловую систему, работающую с запароленным архивом. Так? Сначала fusermount с параметрами в виде пароля, потом лезем в точку монтирования и читаем файлы. open для читаемых файлов вызывается _после_ fusermount.

> Т.е. он не потребует glib и gtk?

:D

GNOME != GTK, GTK != Glib. Это тебе не KDE, где вся функциональность в паре-тройке пакетов.

>>Пардон, а Вы знаете, как это сделать непрозрачно и быстро для "тупых" fрхивов?

> непрозрачно и быстро? tar -xvf

Ну а кто мешает когда нужно, использовать быстрый "tar xvf", а когда скорость не важна - через fuse?

>>go to bugzilla.

> лень :)

нет багрепорта - нет бага

Можно, конечно. Но это дистрибутивный пакет с archlinux.org, которым занимается своя команда мэинтейнеров.

> Да и KDE тут совершенно ни при чем... ;)

Не важно, KDE'шникам надо позубоскалить. Это ведь злые, вендоподобные существа. 8)

>GNOME != GTK, GTK != Glib.

Умник, отсюда следует, что GNOME!=GLIB ?

Конечно. GNOME имеет практически такое же отношение к Glib, как KDE к Glibc.

>Ну не надо до абсурда-то доводить. Да, fuse использует место, но ему _не обязательно_ распаковывать _всё_! Например, получить список файлов из rar-архива можно куда быстрее и менее накладно, чем распаковать архив и сделать ls.

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

FUSE и tar -zxf в этом случае абсолютно одинаковы. АБСОЛЮТНО.

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

>totalcmd использует библиотеку Unrar от автора архиватора, которая делает то же, что fuse или kio, но не распаковывает во временный каталог.

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

Возможно rar и позволяет вытащить из архива только один файл, не распаковывая его, но bzip - нет, т.к. bzip работает только с одним файлом, собранным из директории tar'ом.

Более того, что мешает использовать ту же библиотеку для mc'шного VFS?

Далее, fuse - это всего лишь ядерная обертка вокруг VFS - абсолютно тоже самое, что и userspace обертка в mc. Может быть количество ошибок разное и т.п., но суть одна и та же. Вы понимаете, что fuse магическим образом не вытащит файлы из rar архива - fuse дернет userspace приложение, которое выдернет файл из архива или распакует весь архив, передаст данные в fuse, а fuse потом передаст их обратно в userspace. Видите, сколько ненужных накладных расходов, когда можно сделать _сразу_ вызов этого самого userspace приложения или библиотеки и вытащить нужные файлы и положить их туда, куда хочется (например во временную длиректорию, чтобы все могли этим пользоваться).

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

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

>гм, напиши-ка мне autofs скрипт для ftp и zip. А то что-то я запамятовал

для ftp самое простое:
#!/bin/sh
echo "-fstype=curlftpfs / :$1"

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

>Не понимаю. Мы монтируем файловую систему, работающую с запароленным архивом. Так?

нет. мы передаем ведру команду на открытие файла

задача-то в автоматическом монтировании

грубо говоря, на инод ~/.gvfs вешается (fuse-модуль)

как только идет запрос open('~/.gvfs/Network/ftp/bla.bla.com/pub/бла.rar') -

модуль разбирает путь на

/Network - ага, значит по сети /ftp - ага, значит протокол ftp /pub/ /бла.rar - ага, значит rar

и работает через соответствующий модуль

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

fuse такого не умеет.

внимание вопрос. Программа, которая не знает о существании fuse - ограничена только вызововм open()

следовательно, нуна протокол, координаты сервера, логин/пароль на доступ к серверу, имя архива, пароль к архиву превратить в имя файла.

глаза сломать можно

=)

о чем это я? пока писал - потерял мысль

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

какой техникой ты отмапишь точку монтирования на сам файл?

те. ~/root/blah.tgz у тебя должен стать точкой монтирования для tgz-fs

тут надо ядреный модуль пейсать. Autofs этого не умеет

>гы, ftp:// - cхема. Кто там возмущался по поводу zip:// ?

Я возмущался. Потому что зип может лежать в зипе, а фтп в фтп - нет.

>test.rar - вроде запароленый, нет? Куда пароль пихать?

Забыл. Ну пароль через собаку какнить. Это в общем не обязательно, т.к. небезопасно.

>осознаешь, что весь test.rar стянется по сети? Прозрачность вырождается в нехилую тормознутость.

Это детали реализации. Можно сделать настоящий fseek и кеширование. Тут вообще некоторые предлагали для доступа у файлу в архиве его целиком в /tmp распаковать.

>это надо посикс менять,

Если не реализовывать мою сомнительную идею с изменение глибцов, то посикс не трогается, т.к. на низком уровне всё по прежнему начинается с /. А вот для юзеров - с file:///

Тогда скажи мне, что есть GNOME ?

>нет багрепорта - нет бага

ну формально-то бага нет. Есть отставание unrar-free по поддерживаемым версиям и отсутствие конвертирования кодировки имен файлов

>Тогда скажи мне, что есть GNOME ?

unix-way :)

glib - не часть гнома, и даже не часть gtk. Хотя gtk зависит от glib, а gnome - от gtk. Но gtk - не часть gnome

как всё сложно, да? =)

> Тут все распыляются на Gnome против KDE, а у меня такой вопрос к знатокам разработки гнома. Что они будут делать на системах без FUSE, то есть везде кроме Linux и FreeBSD?

Ничего страшного не произойдёт. FUSE используется в качестве интерфейса для POSIX-приложений. Т.е. GNOME-приложение будет использовать GVFS на любой системе, а не GNOME-пока только на той, где есть FUSE. Впрочем, единственная система, где FUSE нельзя установить при желании - это оффтопик.

http://www.gnome.org/~alexl/presentations/guadec2007-gvfs.pdf

>Я возмущался. Потому что зип может лежать в зипе, а фтп в фтп - нет.

логично, черт подери

>Забыл. Ну пароль через собаку какнить. Это в общем не обязательно, т.к. небезопасно.

пароль к архиву через собаку, или пароль к фтп через собаку?

>Это детали реализации. Можно сделать настоящий fseek и кеширование.

fseek по ftp - это в большинстве случаев кеширование файла локально и seek уже по локальной копии

>Если не реализовывать мою сомнительную идею с изменение глибцов, то посикс не трогается, т.к. на низком уровне всё по прежнему начинается с /. А вот для юзеров - с file:///

бедные юзвери. Запустят консоль - а тут когнитивный диссонанс в табло =)

> GLib — низкоуровневая библиотека, расширяющая возможности, предоставляемые стандартной библиотекой libc языка C.

http://ru.wikipedia.org/wiki/GLib

> GNOME — свободная среда рабочего стола для UNIX-подобных операционных систем. GNOME является частью и официальной рабочей средой проекта GNU.

http://ru.wikipedia.org/wiki/GNOME

То, что код будет вынесен в достаточно низкоуровневую библиотеку - это явный плюс, учитывая то, что этот код можно будет использовать и в KDE.

>>Ну не надо до абсурда-то доводить. Да, fuse использует место, но ему _не обязательно_ распаковывать _всё_! Например, получить список файлов из rar-архива можно куда быстрее и менее накладно, чем распаковать архив и сделать ls.

> Список файлов никому не интересен - его можно взять из заголовка.

Пардон, а то же mc разве список файлов не показывает? Список файлов нужен. И для того, чтобы его взять, не надо распаковавать весь архив.

> А вытащить один файл из архива так не получится, если архив запаролен или заархивирован. Нужно распаковать архив целиком и взять файл. FUSE и tar -zxf в этом случае абсолютно одинаковы. АБСОЛЮТНО.

А в случае более умных форматов архивов типа rar или zip? Раз нет разницы в самых тормозных случаях, зачем использовать решение, которое тормозит _всегда_?

> Усовершенствуйте VFS в MC, чтобы он не распаковывал архив для получения списка файлов, а брал их из заголовка.

Не получится, я уже пытался. Там vfs-скрипт для отдельных файлов вызывается отдельно, так что даже показать распаковщику(unrar), что нужно вынуть сразу 10 файлов не получится, придётся запускать 10 раз по одному.

> Для получения файла по-прежнему нужно распаковать весь архив.

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

>>totalcmd использует библиотеку Unrar от автора архиватора, которая делает то же, что fuse или kio, но не распаковывает во временный каталог.

> Аллах акбар, а куда же она его распаковывает, если не на диск, не в память и не в астрал?

В память. Но НЕ ВЕСЬ архив. Получаем экономию времени и памяти.

> Возможно rar и позволяет вытащить из архива только один файл, не распаковывая его, но bzip - нет, т.к. bzip работает только с одним файлом, собранным из директории tar'ом.

Недостаток tar-а. Его писали, когда архивирование проходило на ленту, а там произвольный доступ не так легко получить.

> Более того, что мешает использовать ту же библиотеку для mc'шного VFS?

Архитектура vfs в mc. См. выше.

> Далее, fuse - это всего лишь ядерная обертка вокруг VFS - абсолютно тоже самое, что и userspace обертка в mc.

Нет. fuse может использовать _любое_ приложение, а vfs от mc - только mc.

> Вы понимаете, что fuse магическим образом не вытащит файлы из rar архива - fuse дернет userspace приложение, которое выдернет файл из архива или распакует весь архив, передаст данные в fuse, а fuse потом передаст их обратно в userspace.

Понимаю. Общность требует жертв.

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

На это тратится время и место на диске. Я уже устал повторять.

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

А что делать с не-гномовскими приложениями?

> Userspace код _всегда_ лучше, т.к. в случае ошибки упадет только приложение, а не вся система.

fuse - Filesystem in USErspace

> о чем это я? пока писал - потерял мысль

Обдумайте, а потом пишите. Если следовать Вашей логике, то и флешки писать надо как-то через device:///storage/usb/flash0/part1, а не смонтировав нужное устройство в /dev/mnt, а потом туда писать

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

>fseek по ftp - это в большинстве случаев кеширование файла локально и seek уже по локальной копии

Неа. Если фтп-сервер нормальный, то fseek - это RETR <смещение>.

>пароль к архиву через собаку, или пароль к фтп через собаку?

ftp://user:passwd@host/pub/stuff/test.rar#passwd@un.rar#somedir1/somedir2/test2 .tar.bz2#un.tar.bz2#myfile

>fseek по ftp - это в большинстве случаев кеширование файла локально и seek уже по локальной копии

Да что ты говоришь! А как же тогда работает такая вещь как "докачка"?

> ftp://user:passwd@host/pub/stuff/test.rar#passwd@un.rar#somedir1/somedir2/test2 .tar.bz2#un.tar.bz2#myfile

Логичнее было бы #:passwd@un.rar#

>Неа. Если фтп-сервер нормальный, то fseek - это RETR <смещение>.

это если нормальный фтп-сервер. Мне нормальные как-то редко попадаются. Может где-то и есть райский уголок, где ftp-демоны правильные и кодировка там уникодная. =)

>Но с другой стороны, а как по-твоему будет реализован GIO, с доступом к содержимому архива для сторонних программ? Все равно же файл придется монтировать куда-то в другое место.

насколько я понимаю - доступ к содержимому архива для сторонних программ в gio/gvfs никак не делается. Только для glib-based

> Надо заняться, думаю, что будет популярно. Только можно я сначала зачёты сдам? ;)

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

>Если следовать Вашей логике, то и флешки писать надо как-то через device:///storage/usb/flash0/part1, а не смонтировав нужное устройство в /dev/mnt, а потом туда писать

это из какого места следует?

>> Более того, что мешает использовать ту же библиотеку для mc'шного VFS?

>Архитектура vfs в mc. См. выше.

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

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

>А что делать с не-гномовскими приложениями?

Разницы нет никакой. Вам сначала нужно запустить что-то, что попытается залезть в архив, например щелкнуть мышкой в nautilus. По этому щелчку nautilus запустит 'fusemount $archive $dst_path', а вместо этого мог бы сделать 'tar -zxf $archive $dst_path', или unrar, или что там нужно для обработки данного файла.

grep $archive никоим образом не замонтирует (куда?) этот файл как распакованную директорию и не запустит grep.

Именно поэтому нет никакой разницы между fuse и userspace обработчиком. FUSE только полезен для какой-нибудь sshfs или ftpfs, когда приложение представляет из себя какую-то оболочку над шеллом.

>Логичнее было бы #:passwd@un.rar#

Пожалуй. Возможно, если поискать, найдутся архивы, где имя_пользователя тоже нужно. Хотя врядли.

Хотя всё равно не логично. Т.к. host мы почему-то передаём после собаки, а test.rar - до.

#ftp:user:passwd@host/pub/stuff/#rar:passwd@test.rar/somedir1/somedir2/#tbz2:te st2.tar.bz2/myfile

Напоминает mc, зато всё в одном стиле. ;)

>Мне нормальные как-то редко попадаются

Тебе сильно не везёт. В сети моего провайдера все сервера умеют retr. Вот с ютф8 сложнее. Приходится ради вендузятников прикручивать перекодировку.

очередное поражение гномотупиц

какие переключалки? ;)

пусть сначала в гноме починят включение numlock при старте гнома ;) без костылей вроде numlockx

>ftp://user:passwd@host/pub/stuff/test.rar#passwd@un.rar#somedir1/somedir2/test 2 .tar.bz2#un.tar.bz2#myfile

[нецензурщина поскипана]

:)

>Да что ты говоришь! А как же тогда работает такая вещь как "докачка"?

хреново работает. И не везде. А что?

>>Если следовать Вашей логике, то и флешки писать надо как-то через device:///storage/usb/flash0/part1, а не смонтировав нужное устройство в /dev/mnt, а потом туда писать

> это из какого места следует?

Из того, что изобретался какой-то очень хотрый механизм, вместо того, чтобы сделать с учётом существующих наработок.

> Приходится ради вендузятников прикручивать перекодировку.

Если FTP-сервер соответствует RFC2640, то перекодировку приходится прикручивать только из-за Total Commander. :(

>[нецензурщина поскипана]

Как и всякий гномер, geek предпочитает именовать файлы так:

file://файл_который_мне_сейчас_нужен

В принципе удобно, но реализаций я пока не встречал :)

> Glib пользует только aRts, AFAIK.

Домашнее задание для контуженных, которые не умеют читать: попробуйте избавиться от зависимостей от libxml2 и libxslt в kdelibs. ;)

На чём они написаны надо напоминать? ;)

>Как и всякий гномер, geek предпочитает именовать файлы так:

без всяких file:// :)

> Да я не говорю, что ето плохо, наоборот. Тока вот на КДЕ будет похоже.

А какая разница для не фанатиков? Придём к тому, что будет большой пласт системных библиотек для кэширования конфигурации, vfs, будущих независимых аналогов Solid и Phonon, расширения dbus как универсальной шины, а KDE и GNOME будут просто рисовать фронтэнды. ;)