https://opennet.ru/openforum/vsluhforumID3/38755.html Jaroslav Sykora представил (http://kerneltrap.org/Linux/Shadow_Directories) реализацию механизма "теневых директорий" (shadow directories), суть которых в возможности интерпретации структурированного файла в виде иерархии директорий. Например, к заархивированным данным можно обратиться через команду "cat hello.zip^/hello.c" или "ls hello.zip^/", где символ "^" является сигналом для интерпретации файла как директории.<br><br><br>Операция разбора данных файла производится на пользовательском уровне, средствами дополнительных FUSE модулей.<br><br><br>URL: http://kerneltrap.org/Linux/Shadow_Directories<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=12480<br> https://opennet.ru/openforum/vsluhforumID3/38755.html#24 Tue, 23 Oct 2007 03:45:12 GMT &gt;&gt;ну, а почему бы и нет... <br>&gt;<br>&gt;А зачем ^ надо?Чем запись /folder/file.zip/cool-file-in-zip.txt например невалидна?Налетев на факт что file.zip <br>&gt;файло а не дира и cd не катит - можно мля, <br>&gt;посмотреть что это за дрянь и дальше парсить уже как зипарь.Зачем <br>&gt;какие-то извращения с ^ надо?Потому что так халтурщикам парсить проще?Зато юзерам <br>&gt;обучаться под это - убиться можно.Сами будете секретуток учить этим премудростям.А <br>&gt;так они бы считали архив за нечто типа точки монтирования - <br>&gt;достаточно 1 раз 1 понятие вдолбить и телемаркет :) <br><br>А если find или ls тебе не нужно содержимое архива вываливать? Я предпалагаю для этого и придумали ^, чтоб не патчить программы.<br> https://opennet.ru/openforum/vsluhforumID3/38755.html#23 Mon, 22 Oct 2007 19:46:08 GMT &gt;Применение в практике - 100% вреда, тем более при нынешней цене на <br>&gt;носители. <br><br>Ну не 100%.Как насчет LZ-based алгоритмов которые быстры в декомпрессии?Они иногда столь быстры что может выйти выигрыш в скорости.Просто потому что меньше читается с тормозного по своей сути харда.Не верите?Посмотрите на алгоритмы типа UCL и LZO, у них декомпрессия с немеряной скоростью - на современном скорее в HDD упрется чем в их скорость работы :)<br> https://opennet.ru/openforum/vsluhforumID3/38755.html#22 Mon, 22 Oct 2007 16:24:01 GMT &gt;А вот зачем хитрые символы изобретать для интерпретора? <br><br>Вот этого я не понял.Если немного изменить логику разборта пути и при ошибке cd глянуть что это файл и прикинуть его формат и далее разруливать иерархию через соотв. обработчик - было бы отлично.И что интереснее, не вижу никаких препятствий к этому.Кроме несколько большего объема кодинга.Да, такое поведение надо закодить.А с крышкой можно от этого отмазаться.<br><br>&gt;Есть ведь команда mount, <br><br>Дядя, я конечно понимаю что в ваши годы слово usability не слышали.Но монтировать зипарь чтобы посмотреть его содержимое... нет, технически тому никаких проблем нет.Но ГЕМОРРОЙНОСТЬ этого метода для юзера - внушает!<br><br>&gt;среде? Такие вот ламеры делают очень просто - пишут одно и <br>&gt;то же трижды, на каждый конкретный случай. <br><br>Да, а вы как самый умный наверное монтируете каждый зипарь чтобы посмотреть его содержимое?Ок, а если зипарей 20?А не запаритесь моунтить то???<br><br> https://opennet.ru/openforum/vsluhforumID3/38755.html#21 Mon, 22 Oct 2007 15:24:03 GMT опять грустный клоун вылез из своего шатра и решил доставить немного бесплатного фана<br> https://opennet.ru/openforum/vsluhforumID3/38755.html#20 Mon, 22 Oct 2007 10:08:36 GMT &gt;Это они правильно идею от Plan 9 подхватили, - всё есть файл, <br>&gt;- но только вот реализация этих принципов в линукс слишком дорого <br>&gt;стоит - пространство имён одно на всех и обслуживается ядром. Архитектура <br>&gt;не та, всё равно, что крылья к паровозу прикручивать. Красиво, конечно, <br>&gt;но не летает :-)<br><br>дурак ты боцман, и шутки у тебя дурацкие...<br><br>В каком году до нашей эры ты последний раз видел Линух?<br>Будешь гордиться шо в пятисотом? Ну молодчинко.<br>Потому как трепаццо ты можешь, а знать о чем говоришь - несколько тяжелее.<br><br>Иди смотри "User Namespaces", опция CONFIG_USER_NS.<br>Вместе с Documentation/sharedsubtree.txt неплохо пойдет на пользу.<br><br><br>&gt;А вот зачем хитрые символы изобретать для интерпретора? Есть ведь команда mount, <br>&gt;она все файловые системы и должна обслуживать. Смонтировал с ключами соответствующими <br>&gt;- и юзай всеми стандартными утилитами и скриптами без изменений. Файл <br>&gt;- он и в африке файл, а если то - это <br>&gt;файл, а это - это файл, да не такой, а третье <br>&gt;- вообще на файл не пох https://opennet.ru/openforum/vsluhforumID3/38755.html#19 Mon, 22 Oct 2007 09:42:42 GMT Это они правильно идею от Plan 9 подхватили, - всё есть файл, - но только вот реализация этих принципов в линукс слишком дорого стоит - пространство имён одно на всех и обслуживается ядром. Архитектура не та, всё равно, что крылья к паровозу прикручивать. Красиво, конечно, но не летает :-)<br><br>А вот зачем хитрые символы изобретать для интерпретора? Есть ведь команда mount, она все файловые системы и должна обслуживать. Смонтировал с ключами соответствующими - и юзай всеми стандартными утилитами и скриптами без изменений. Файл - он и в африке файл, а если то - это файл, а это - это файл, да не такой, а третье - вообще на файл не похож, как софт разрабатывать в такой среде? Такие вот ламеры делают очень просто - пишут одно и то же трижды, на каждый конкретный случай.<br> https://opennet.ru/openforum/vsluhforumID3/38755.html#18 Mon, 22 Oct 2007 06:47:55 GMT +1<br> https://opennet.ru/openforum/vsluhforumID3/38755.html#17 Mon, 22 Oct 2007 06:26:33 GMT Если из архива читают - это не так страшно. А вот если в архив что-то записывают, то тут загрузка процессора и диска взлетают до небес, и надолго.<br><br>Хотя для Апача это было бы весьма удобно - на диске хранятся архивы, из которых на лету выдёргиваются файлы, причём ещё и кэшируются в раззипованном виде. За счёт бОльшей компактности растёт КПД дискового кэша, хотя возрастает нагрузка на процессор.<br> https://opennet.ru/openforum/vsluhforumID3/38755.html#16 Mon, 22 Oct 2007 04:53:18 GMT +/dev/hands<br>