Artie
Профи в Сат-ТВ
georg30, давайте, все-таки оставим за рамками лирику - в данном контексте никому другому все это здесь неинтересно и неконструктивно, если желаете, дайте знать ч/з ЛС: могу объяснить свою позицию касательно дополнения поста и прокомментировать Ваши в связи с этим выводы.
А вот "чистка DOM форматированием/ручная" по-прежнему остается темой животрепещущей, и поскольку Ваше мнение на этот счет, как я считаю, ошибочно и может ввести в заблуждение других - я Вам ответил и прокомментировал это в предыдущих постах. К большому сожалению, я - профессиональный программист, занимаюсь этим делом уже 18 лет и, поверьте: самую малость - понимаю, о чем говорю и держу за свои слова ответ.
И еще раз могу Вам сказать, не вдаваясь в ненужные технические детали: после форматирования (настоящего, такого, как, допустим, форматируют в компьютере флешку) - на любом носителе ничего не остается - проинициализированная пользовательская часть файловой системы и теоретически, и фактически, является и для операционной системы, и для пользователя пустой.
То, что Вы показали под "мусором" через редактор - низкоуровневый просмотрщик секторов, это не "мусор", а нормальное явление пустого носителя, и оно в нашем случае никак не влияет на обычную работу программ и операционной системы, будь то компьютера, ресивера, мобильного телефона и т.д. Могу еще раз объяснить, тоже без особых технических подробностей, "на пальцах", почему это не мусор и почему этот "не мусор" не влияет на операционную систему.
Немного "примитивной" теории.
Что из себя представляет файл на диске? Группа блоков с данными (секторов), никак друг с другом физически не связанными. Содержимое этих блоков, там и тут разбросанное по диску, как раз и представляет собой виденный Вами "мусор". А вот задача файловой системы и ее драйверов в данном контексте - обеспечить доступ пользователю к конкретному файлу, и она определенным образом хранит информацию о физическом размещении блоков файла в специальных таблицах (т.н. "таблицах размещения файлов").
Поэтому на "низком уровне" структура диска - хаотичный набор блоков данных. На "высоком уровне" (логическом, пользовательском) - это набор файлов и папок.
Пример:
Удаляли файлы с жесткого диска? Это происходило быстро? Копировали файлы на жестком диске? Это происходило медленно? Почему?
Потому, что при копировании данные поверху перезаписываются в физические блоки на диске, а при удалении файла физические блоки не затрагиваются, удаляется только ссылка на этот файла в таблице размещения файлов.
Похожее происходит и при "высокоуровневом" форматировании, особенно флеш-носителей, поскольку физическая организация данных на них отличается от жестких дисков, но общий принцип для операционой системы и пользователя - тот же.
Итак - "мусор" остается, но операционная система не знает, как этот "мусор" упорядочен - она просто его не способна читать, и это большая проблема для системы, особенно, кстати, для Linux. С этим сталкиваются люди, у которых "слетел" диск, и поверьте, это не самые лучшие минуты в их жизни.
Да, существуют программы восстановления удаленных файлов и дисков после переформатирования, но... скорее всего Вы все равно потеряете массу данных. И чем быстрее выполнить восстановление, тем больше шансов на успех, т.к. любые манипуляции с диском влияют на содержимое блоков и таблиц их размещения.
О принципах действия подобных утилит отсылаю к Google.
Наводка, по степени эффективности: R-Studio, EasyRecovery Professional, а так же TestDisk и др.
Да и само восстановление - процесс очень длительный, неужели Вы думаете, что "хитрое" программное обеспечение ресивера способно заменить собой эти специализированные утилиты, восстанавливая нужные ей данные "на лету" из неупорядоченных физических блоков с "мусором", поскольку чистый отформатированный DOM она читать неспособна?
В общем случае, если что-то и остается (в чем я глубоко сомневаюсь) в DOM после форматирования по пункту 4, то это что-то, способное влиять на пользовательскую часть операционной системы, должно быть видно как раз штатными пользовательскими средствами самой операционой системы (это к вопросу о Far-менеджер и т.д.).
Насчет конкретного случая с сохранением акселерации, приведу пример: принято при "разгоне" компьютера изменять настройки аппаратуры(частоты, вольтаж и т.д.) в BIOS .
Разумно предположить, что в AzBox аппаратный разгон настраивается тоже в его EEPROM - компьютерном аналоге BIOS, а не сохраняется в каком-нибудь конфигурационном файле прошивки Linux в DOM, поскольку начальная инициализация "железа" всегда выполняется раньше инициализации операционной системы, а пункт меню "Аппаратное ускорение" просто "правит" эти настройки EEPROM. Косвенным подтверждением этому является требование перезагрузки ресивера после вкл./выкл. акселерации.
Поэтому даже при форматировании DOM статус акселерации сохраняется.
Почему в 90% сохраняется, а не в 100%? А черт его знает, это уже вопрос к разработчикам, может при первой инициализации в одной прошивке по умолчанию флаг акселерации сбрасывается, а в другой - нет.
Без комментариев.
P.S. Если все это для Вас по-прежнему демагогия, я "умываю руки" и прошу по этому вопросу меня больше не беспокоить!
P.P.S. Сегодня вечером отформатирую и сниму DOM, посмотрю на работе, что там, но, разумеется, смотреть буду то, что считаю нужным для себя и для других - кому это действительно нужно, и, как ни странно, именнно Far-менеджером...
P.P.P.S. только время впустую потратил...
Последнее редактирование:
