» HandyCache ( Часть 4 )

rs

Цитата:

а если логи
-потеряются?
-случайно (неслучайно) очистятся?
-окажутся с прерывистым временнЫм охватом файлов кэша?
-окажутся соответствующими ДРУГОМУ кэшу?
и т.п.

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

Существует "множество потенциальных моментов рассинхронизации и неполноты данных" в паспортах (потоках) и в кэше!
И главные из них - человеческий фактор и технические проблемы!
В общем, волков бояться - в лес не ходить!

Все, что тебе надо для полноценной Статистики, уже сейчас есть в логах Монитора!

Заметь, что паспорта к файлам, которые сейчас у каждого накоплены в многомегабайтных кэшах не появятся волшебным образом! Так что, получить паспорта для каждого файла в кэше не смогу ни я, ни ты, ни кто другой из "фанатов" HC. Это доступно только новичкам, если они не будут отключать эту фичу, в чем я не уверен...

Поэтому "жёсткой связанности и обусловленности (безусловности)", синхронности и полноты данных не будет никогда или почти никогда! Это утопия!

DenZzz

Цитата:

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

если отложить шутки в сторону, то из конкретно перечисленных ТОБОЙ опасностей РЕАЛЬНЫХ для "паспортной" реализации я не вижу ни одной. это связано с тем, что потеря отдельных файлов (пусть даже половины) паспортов НИКАК не затронет непотеряных паспортов. если же завалится по любой из причин индекс, хранящий сведения обо ВСЕХ файлах в кэше, то не останется ВООБЩЕ НИЧЕГО, никакой доп. информации о файлах кв кэще, кроме самъ файлов в кэше!

второй вариант мне совершенно не нравится!


Цитата:

Существует "множество потенциальных моментов рассинхронизации и неполноты данных" в паспортах (потоках) и в кэше!

нет, опасностей с отдельными на файл в кэще паспортами на порядок меньше
пусть к примеру нужно сложить N кэшей с разных машин, значит нужно иметь в суммарном кэше N незатирующих друг друга индексов (сразу вопрос об уникальном именовании индексов);
далее - переписали в один каталог суммарного кэша N кэшей, каждый из которых
содержит одну и ту же страницу, но с разными датами посещения и разными пользователями - в результате прямого копирования файлов кэша по существующе на сегодня технологии останется ОДИН файл этой страницы в суммарном кэше, но N индексов с N записями об этой ОДНОЙ странице - что выберем?
далее - опять же при слиянии по какой либо причине некоторые индексы перетерлись по разным причинам прямого файлового копирования - осталось N-K файлов индексов - опять рассинхронизация

и т.д. и т.п.

при копировании пар файл-кэша+файл-паспорта такие проблемы невозможны изначально

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

поток, btw, не плодят точки входа в MFT, в отличие от обычных парных паспортов


Цитата:

Поэтому "жёсткой связанности и обусловленности (безусловности)", синхронности и полноты данных не будет никогда или почти никогда! Это утопия!

в абсолютном понимании - утопия
но один расклад проблемами с ОДНИМ файлам индекса создаёт проблемы для ВСЕХ файлов кэша, а при другом раскладе ВСЕ проблемы ЛОКАЛЬНЫ по отношению к каждому проблемному файлу в кэше в отдельности, НИКАК не вредя остальным файлам кэша (повторюсь, при хранении паспортов в потоках эти паспорта даже нельзя стереть нечаянно)


Цитата:

В общем, волков бояться - в лес не ходить!

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


Цитата:

Все, что тебе надо для полноценной Статистики, уже сейчас есть в логах Монитора!

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


Добавлено:
forever
Цитата:

Да, хочу конкретный пример. Ежели не в тягость утолить мое любопытство

для "C:\Program Files\HandyCache\Cache\forum.ru-board.com\topic.cgi^\forum=5&topic=20528&start=960" имеем либо дополнительный ntfs-поток, либо файл-паспорт "C:\Program Files\HandyCache\Cache\forum.ru-board.com\topic.cgi^\forum=5&topic=20528&start=960.pssp" (о расширенни, иднтифицируещем паспортный файл, или об иной сигнатуре в имени файла всегда можно договориться)

файл-паспорт "C:\Program Files\HandyCache\Cache\forum.ru-board.com\topic.cgi^\forum=5&topic=20528&start=960.pssp" создаётся при включённой галке HC, включающей паспортизацию. кроме того, со временем и при желании можно включать-выключать создание паспортов списками условий с регулярными выражениями

далее, этот файл паспорта содержит (может содержать):
u006Ивановd2006.10.0318:15:00

здесь тега два:
u - user? следом число-длина имению пользователя
d - дата выдачи файла историком (из нета или из кеща) - дата последнего доступа

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

то же самое (u006Ивановd2006.10.0318:15:00) можно записать в поток, что ещё лучше





Добавлено:
DenZzz
кроме прочего, я не зря говорил о том, что есть проблема конкуретного одновременного, но разделяемого, доступа к обычным файлам - логамЮ индексам

для таких вещей подходят СУБД, чем индексы и логи не являются

паспортный же подход лишён и этих проблем

зы
под паспортной для определённости будем понимать любую из двух реализаций: в ntfs-потоке или в парном файлу кэша обычном файле-паспорте

Поспрашивал тут про потоки NTFS на форуме каспера.
Мне ответили, что KAV не мешает другим прогам создавать/читать альтернативные потоки данных. Так что нестыковка с KAV отпадает.

rs я думаю, что в принципе надо не так уж много. Балланс трафика по выбранным и, или, всем пользователям прокси сервера - 2 столбца - входящий и исходящий, сумма по пользователю и по всем выбранным пользователям, возможность задавать дату и время начала и конца анализа с точностью до минут (желательно), ввести графу имя рабочей станции - IP не нужен так как все равно в больших сетях динамическая адресация. Если есть возможность построить гистограмму - для босса. Можно сделать возможность экспорта всего анализа в Exel например. Очень хорошо все это реализованно в WinRoute Spy. А что до стоимости траффика то прога некоммерческая ну и не надо. Вот и все пожелания.

rs

Цитата:

если же завалится по любой из причин индекс, хранящий сведения обо ВСЕХ файлах в кэше, то не останется ВООБЩЕ НИЧЕГО, никакой доп. информации о файлах кв кэще

Кто мешает сделать резервное копирование индекса (например, при закрытии HC или через какой-то интервал времени)?! Кроме того, здесь уже предлагалось сделать по отдельному индексу на хост!
Поэтому потерять ВЕСЬ индекс сразу практически НЕВОЗМОЖНО !!!

Цитата:

сразу вопрос об уникальном именовании индексов

Это не проблема! Указал в настройках HC на разных компах уникальный идентификатор и всего делов.
И будет у тебя дома - index1.idx, на работе - index2.idx и т.д.

Цитата:

N индексов с N записями об этой ОДНОЙ странице - что выберем?

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

Цитата:

далее - опять же при слиянии по какой либо причине некоторые индексы перетерлись по разным причинам прямого файлового копирования - осталось N-K файлов индексов - опять рассинхронизация

Растерять при копировании потоки гораздо легче! Ты не забывай, что для копирования потоков по LAN, через Флэшку или CD надо использовать RAR с обязательно включенным сохранением потоков! Сам-то об этом не забудешь? А простым пользователям кто будет напоминать?

Цитата:

поток, btw, не плодят точки входа в MFT, в отличие от обычных парных паспортов

А где же хранится инфа о расположении потоков? В одной записи MFT все может не уместиться! А файлы размером до 1 кБ (паспорта) могут храниться прямо в MFT.

Цитата:

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

Ты о чем? Сразу после записи лога Монитора на диск, он доступен для любой другой программы! HC не держит его открытым! Аналогично "Историк" сейчас обрабатывает очередь последних посещённых ссылок...

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

меня беспокоит именно второй вариант (поскольку именно такой для меня и является саммым ходовым)

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

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

Да, я и сам, признаться, начал понимать что к чему. Я предполагаю использовать сабж на сервере (не для коммерции, конечно же) по этому вопрос с анализом логов на 1 машине для меня, конечно же более актуален. В принципе пробовал использовать сабж в качестве Parent Proxy но что-то не очень то катит. Так то все красиво выходит но не использует конечный прокси кэш Handy а только прозрачно через него выходит в нет, хотя ханди что то там кэширует... Связка была WinProxy+Handy еще есть план попробывать Proxy+ и Handy... Посмотрим, что к чему.

DenZzz

Цитата:

Кто мешает сделать резервное копирование индекса (например, при закрытии HC или через какой-то интервал времени)?! Кроме того, здесь уже предлагалось сделать по отдельному индексу на хост!

частично это конечно решает проблему
но всё равно - яйца больше в одной корзине, чем каждое само по себе


Цитата:

Это не проблема! Указал в настройках HC на разных компах уникальный идентификатор и всего делов.
И будет у тебя дома - index1.idx, на работе - index2.idx и т.д.

могу согласиться


Цитата:

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

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


Цитата:

Растерять при копировании потоки гораздо легче! Ты не забывай, что для копирования потоков по LAN, через Флэшку или CD надо использовать RAR с обязательно включенным сохранением потоков! Сам-то об этом не забудешь? А простым пользователям кто будет напоминать?

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

если у ж очень опасаешься - используй обычные паспортные файлы


Цитата:

А где же хранится инфа о расположении потоков? В одной записи MFT все может не уместиться! А файлы размером до 1 кБ (паспорта) могут храниться прямо в MFT.

а где хранится информация о кластерах, входящих в длинный многокластерный файл, а?



Цитата:

Ты о чем? Сразу после записи лога Монитора на диск, он доступен для любой другой программы! HC не держит его открытым!

а если я полезу в него именно в момент записи туда hc?


Цитата:

Аналогично "Историк" сейчас обрабатывает очередь последних посещённых ссылок...

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


Добавлено:
unreal666
Цитата:

Поспрашивал тут про потоки NTFS на форуме каспера.
Мне ответили, что KAV не мешает другим прогам создавать/читать альтернативные потоки данных. Так что нестыковка с KAV отпадает.

да было б странно, если б мешал - по сути-то ЛЮБОЙ файл на ntfs состоит из потоков - так гласит вчерашняя статья

rs

Цитата:

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

И я о том же! HC видит N индесов в одной папке и просто сливает инфу из них в один! Это чисто техническая процедура: разных пользователей - добавляет, дату доступа - обновляет и т.д. В новом индексе остается 1 запись на 1 файл в кэше, но в ней будет 2 пользователя, последняя (более свежая) дата доступа и т.д.

Цитата:

а где хранится информация о кластерах, входящих в длинный многокластерный файл, а?

В нем родимом - в MFT... Чем больше файл, чем больше фрагментов разбросаны по диску - тем больше записей MFT будет использовано на 1 файл, если одной записи уже не хватает.

Цитата:

а если я полезу в него именно в момент записи туда hc?

А ты не лезь! Сделай тайм-аут, как в "Историке"!

Цитата:

hc, записав файл в очередь, теряет к нему интерес навсегда

Аналогично и с логами Монитора! Записав лог, следующий HC будет писать с другим именем - в имя файла лога добавляется время его начала...

DenZzz

Цитата:

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

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


Цитата:

В нем родимом - в MFT... Чем больше файл, чем больше фрагментов разбросаны по диску - тем больше записей MFT будет использовано на 1 файл.

во вчерашней статейке не так прописано


Цитата:

А ты не лезь! Сделай тайм-аут, как в "Историке"!

сделаю, потом полезу после выдерживания таймаута... а тут hc проснулся и решил, что ему пора в лог писать

а с индексом как делить доступ с hc буду?

Добавлено:

Цитата:

Аналогично и с логами Монитора! Записав лог, следующий HC будет писать с другим именем - в имя файла лога добавляется время сохранения..

а незакрытый лог монитора я уже и тронуть не могу? и долго ждать, пока смогу? сколько - долго?

rs

Цитата:

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

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

Цитата:

во вчерашней статейке не так прописано

Почему же, именно так и написано:

Цитата:

Прежде всего, обязательный элемент - запись в MFT, ведь, как было сказано ранее, все файлы диска упоминаются в MFT. В этом месте хранится вся информация о файле, за исключением собственно данных. Имя файла, размер, положение на диске отдельных фрагментов, и т.д. Если для информации не хватает одной записи MFT, то используются несколько, причем не обязательно подряд.

Цитата:

сделаю, потом полезу после выдерживания таймаута... а тут hc проснулся и решил, что ему пора в лог писать

HC будет писать лог уже в другой файл, а не в тот, который ты будешь читать...

Цитата:

а с индексом как делить доступ с hc буду?

HC же не будет держать индекс постоянно открытым - mai62 говорил, что индексы будут обрабатываться в памяти и временами скидываться на диск...
А зачем тебе лезть в индексы HC? Кесарю - кесарево! В индексах HC "Историку" делать нечего - пусть HC сам с ними разбирается! А "Историку" и логов Монитора хватит...

Цитата:

а незакрытый лог монитора я уже и тронуть не могу? и долго ждать, пока смогу? сколько - долго?

Универсальное решение - до появления более свежего лога. А вообще, HC ведет лог в памяти, а потом просто скидывает его в новый файл (при закрытии HC, очистке Монитора или через настраиваемое количество записей).

Прописал прокси сервер в настройках, жму на браузер вылетает окно (пароль логин) ввёл ОК а оно снова типа не правильно - всё перепроверил перенабирал - одна байда. Не пойму чё терь делать ?

rs

Цитата:

файл-паспорт "C:\Program Files\HandyCache\Cache\forum.ru-board.com\topic.cgi^\forum=5&topic=20528&start=960.pssp"

Максимальная длина имени файла, и максимальная длина URI одинакова. Твои пять символов ".pssp" могут вызвать конфликт. Но это просто к сведению.


Цитата:

далее, этот файл паспорта содержит (может содержать):
u006Ивановd2006.10.0318:15:00

здесь тега два:
u - user? следом число-длина имению пользователя
d - дата выдачи файла историком (из нета или из кеща) - дата последнего доступа

Для одного файла может быть несколько юзеров/дат? Как это будет выглядеть?


Цитата:

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

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


Цитата:

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

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


Цитата:

под паспортной для определённости будем понимать любую из двух реализаций: в ntfs-потоке или в парном файлу кэша обычном файле-паспорте

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


Цитата:

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

Собственно RAR тоже зашит в Историка? Небось еще и лицензия прилагается?

lagi

Цитата:

вылетает окно (пароль логин) ввёл ОК а оно снова типа не правильно

НС - Настроки - Доступ. Убедись, что у тебя разрешен доступ (стоит галочка) для пользователя с именем local и с IP 127.0.0.1 (графа Пароль должно быть пустым).
Если проблема останется - попробуй вводить в браузере другой адрес - видимо пароль спрашивает сайт, а не НС.

Цитата:

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

Ну блин сравнил. Или машину свиснут или колесо от машины (и притом запасное). Одно и тоже.

Добавлено:

Цитата:

(графа Пароль должно быть пустым)

Необязательно. Можно и с паролем.

unreal666
А с чего индексный файл стал "машиной"? Нет индекса = нет у нескольких файлов пачпорта. Всего то.

Цитата:

нет у нескольких файлов пачпорта.

Может у нескольких, а может у нескольких тысяч.

unreal666
Если индекс один на весь кэш то да. Но один индексный файл - не лучшее решение. Хотя с какой стороны смотреть. У Оперы все в одном индексном файле и никаких проблем ни со скоростью, ни с надежностью. Но там не стоит вопроса слияния кэшей, хотя трудностей или чего-то невозможного в этом нет.

У меня вопрос: а откуда изначально берутся http-заголовки? Сервер-отправитель ведь не хранит Content-Type для каждого файла. Понятно куда клоню?

Цитата:

У меня вопрос: а откуда изначально берутся http-заголовки? Сервер-отправитель ведь не хранит Content-Type для каждого файла.

Ну так ведь для серверных сценариев страницы (а иногда и дргие типы файлов, например вложения) то хранятся не с таким же расширением, с каким мы получаем. Да и у них еще есть всякие .htaccess и mod_rewrite и базы данных для получения реального имени и типа файла.

unreal666
Ну а нам то зачем хранить Content-Type для каждого файла? До того как файл был запрошен обработали URL прочими списками/правилами. Пришел заголовок - обработали, выполнили назначенное для этого типа действие.
Хотя, мне бы хотелось увидеть какойнить реальный, ненадуманный пример, когда нельзя обойтись имеющимися правилами и нужен еще "последний редут" - фильтрация по Content-Type.

forever
Для меня основная польза - это сохранение в кэш и НЕ обновление картинок, которые имеют нестандартные расширения (или вообще без расширений). Такие картинки часто встречаются на форумах (внедренные картинки, прикрепленные файлы).

unreal666

Цитата:

которые имеют нестандартные расширения (или вообще без расширений).

URL то они имеют? Есть URL - есть что обрабатывать правилами.

Цитата:

Есть URL - есть что обрабатывать правилами.

По URL у таких файлов не определишь тип файла. Не буду же сохранять все (в том числе и прикрепленные архивы) с форумов. Кэш не резиновый. Да и не обновление я не смогу поставить. Да и для каждого форума вычислять спецкусок URL, который отличает их от других файлов, накладно.

unreal666

Цитата:

Для меня основная польза - это сохранение в кэш и НЕ обновление

Цитата:

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

Хлебни 7UP и внеси ясность.

forever
Например ссылки вида
http://site.com/attachment.php?attachmentid=2134&stc=1
Это могут быть и архивы и картинки. Архивы мне сохранять не надо, а вот картинки надо сохранять и не обновлять.

unreal666
Это ссылка, а не URI

Цитата:

Это ссылка, а не URI

А чем 1-ое от 2-го отличается?

unreal666

Цитата:

URL это URI, который, помимо идентификации ресурса, предоставляет ещё и информацию о местонахождении этого ресурса.

В твоем примере ссылка ведет на скрипт, который по полученным параметрам выдаст "реальную ссылку". Загружается же файл из известного места с известным именем. И сохраняется в кэш не как attachmentid2134 а под вполне определенным именем соответствующему URI.

Цитата:

В твоем примере ссылка ведет на скрипт, который по полученным параметрам выдаст "реальную ссылку".

Нет. Это именно URL файла. Так они приаттачиваются на сайте club.cdfreaks.com .

forever

Вот реальный URL с картинкой:
http://virusinfo.info/attachment.php?attachmentid=3407&d=1159793207
(нужна регистрация на форуме)

Вот ответ сервера:

Код: 04.10.2006 7:35:15 # 256 <<< URL: http://virusinfo.info/attachment.php?attachmentid=3407&d=1159793207
HTTP/1.1 200 OK
Date: Wed, 04 Oct 2006 02:35:07 GMT
Server: Apache
Cache-control: max-age=31536000
Content-disposition: inline; filename="Image1.jpg"
Content-transfer-encoding: binary
ETag: "3407"
Expires: Thu, 04 Oct 2007 02:35:07 GMT
Last-Modified: Mon, 02 Oct 2006 12:46:47 GMT
Content-Length: 127481
Content-Type: image/jpeg

unreal666
Под каким именем они сохраняются в кэше? С какого URL качаются (смотреть в логе НС)?

Добавлено:
О, народ уже просыпается. DenZzz, гутен морген.

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