Возможности NTFS для хранения настроек вашей программы

    imageВ Windows существует несколько способов хранить настройки программы. Реестр, ini файлы, другие типы файлов (по усмотрению разработчика). Порой удобнее одно, порой другое… У каждого подхода есть свои преимущества и свои недостатки. Предлагаю разобраться что лучше и предложить альтернативу, сочетающую в себе преимущества нескольких подходов.

    Реестр удобен тем, что настройки лежат все в одном месте и не болтаются рядом с программой. Но не совсем удобно если нужно использовать несколько копий одних и тех же программ(утилит), но с разными настройками одновременно. Тогда приходится при написании программы учитывать это и придумывать что-нибудь, что бы реализовать сохранение отдельно для каждой копии программы. Например, выделять ключ реестра, в который будет включено так же название исполняемого файла.
    *.ini файлы, а так же другие файлы настроек удобны тем, что хранят настройки той программы, с которой непосредственно находятся. Таким образом, можно держать несколько копий программ с разными настройками (причем, только тогда, когда программы в разных директориях). Но приходится таскать рядом с программой эти файлы. А если программа не большая, в которой достаточно одного exe файла, и никаких лишних файлов и ресурсов больше не требуется, то эти файлы настроек как груз висят над душой.
    Хочу рассказать об альтернативном месте, где можно сохранить настройки программы так, что бы рядом с ней не было никаких файлов настроек, и в то же время для каждого exe файла были свои настройки, даже если они находятся в одной директории. Данный способ работает только на NTFS, т.к. используются возможности самой файловой системы.
    У файлов в NTFS есть так называемые «файловые потоки».

    Каким образом это реализовано? Любая информация о файле, начиная с его имени, разрешений и заканчивая собственно данными, хранящимися в файле, с точки зрения NTFS представляет собой атрибут, хранящийся в собственном потоке (stream).
    image
    Обычно у файла один поток — главный. А вообще у любого файла может быть сколько угодно потоков. Многопоточный файл представляет собой разновидность коллекции однопоточных файлов, которая с точки зрения пользователя выглядит как неделимая единица. На самом же деле это набор файлов-потоков, каждый из которых можно независимо создавать, редактировать и удалять. У каждого дополнительного потока есть символьное имя, через которое можно обращаться к данным в этом потоке. Например «Program.exe:stream». Сам поток создается при первом открытии на запись и дальше можно работать с ним как с обычным файлом.
    Вот пример кода на С++, для работы с потоком.
    void read_settings(){
    	try{
    		ifstream file("Program:settings");
    		char* ProgramTitle = new char[256];
    		file >> ProgramTitle;
    	}
    	catch(...){
        		//сообщение об ошибке если требуется
    	}
    }

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

    Данный способ хранения настроек удобен, если приложение не большое и состоит из одного исполняемого файла. А так же хранение настроек в потоке в некотором смысле повышает безопасность, т.к. можно прочитать информацию, только если знать имя потока. А вот узнать какие потоки есть в файле и вообще есть ли они там, не всегда просто. Скорее всего, есть API функции, которые позволяют узнать, какие потоки есть в файле. Но человек совершенно не подозревающий об их существовании данных возможностей не догадается, где хранятся настройки.
    image
    Существуют небольшие недостатки данного способа. Надо иметь ввиду, что при переносе такого файла в раздел с другой файловой системой копируется только основной неименованный поток. Имеет смысл использовать такие файлы только с файловой системой NTFS.
    Так же если захотим перенести настройки куда-нибудь в отдельное место, то придется писать процедуру экспорта.
    Но в остальном я считаю такой способ достаточно гибким и удобным. Получаются портативные приложения с возможностью конфигурации.

    Средняя зарплата в IT

    120 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 8 924 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 38

      +6
      Обновление прораммы удалит настройки. Это ещё один минус.
        +3
        Жуткое извращение. Масса минусов:
        1. Свободное место на диске не соответсвует ёмкости. Сразу появляется подозрение на руткиты.
        2. Программа зависает, оставляя настройки в некорректном состоянии. Лечится только переустановкой.
        3. Поделившись с другом прикольной программой, пользователь незаметно для себя делится паролями.
          0
          1. По поводу свободного места. Настройки весят мизер, так что этого даже и заметно не будет.
          2. А с чего это программа при зависании оставит настройки в некорректном состоянии? Даже если что-то испортится, можно запросто очистить настройки. (работа с потоками происходит так же как и с обычными файлами)
          3. Ну во первых пароли в открытом виде давно никто не хранит, а во вторых, для того, что бы этот самый пароль (зашифрованный) вытащить, придется повозиться.
          Ну а вообще я писал, что этот способ удобен, если приложение не большое и состоит из одного исполняемого файла.
            +1
            1. Многие сканеры руткитов и на мизер реагируют.
            2. Программы иногда зависают, это правда жизни. Представьте, что Вы установили в игре некорректное разрешение экрана, и пришлось её аварийно завершить. Больше Вам её запустить не удастся, пока не исправите найстройку. В случае конфигурационного файла или реестра проблема легко решаема.
            3. Ну, если программа может расшифровать пароль перед его использованием, почему хакер не сможет?
              –1
              1. Я думаю что сканеры руткитов должны учитывать стандартные особенности NTFS. И то что в файлах могут использоваться потоки.
              2. Ну для таких больших программ, как игры, я думаю что данный метод не очень подходит. И тем более я считаю, что разработчик сам должен позаботиться о том, что бы подобные случаи вообще не могли произойти.
              3. Ну чаще всего в таких файлах хранятся не сами пароли, а хэш функции от них. А проверка идет от того пароля, которые вводит пользователь. Совпадает ли хэш функция введенного пароля, и та хэш функция, что хранится в настройках.
                +1
                1. Ладно, уговорили
                2. Игры и небольшие бывают
                3. Мессенджеры, например, хранят именно пароли, и у пользователя ничего не спрашивают
                +2
                1. Многие сканеры руткитов и на мизер реагируют.

                Касперский в потоках хранит свои данные для каждого файла (технология проверки только изменившихся файлов), еще ни одна проверка не заподозрила в этих данных руткит, так что тут более-менее безпроблемно.
                  0
                  2. Программы иногда зависают, это правда жизни. Представьте, что Вы установили в игре некорректное разрешение экрана, и пришлось её аварийно завершить. Больше Вам её запустить не удастся, пока не исправите настройку. В случае конфигурационного файла или реестра проблема легко решаема.
                  — Чего это? Зная имя потока можно открыть его например в блокноте и поправить.
                    0
                    2. А зачем туда что-то писать постоянно и на каждом шаге? При запуске прочитали, при закрытии (или сохранении) — записали. Таких ситуацией быть не должно в нормальном софте.
                      0
                      В нормальном софте много чего не должно быть, что тем не менее встречается в реальности. Например, любое оконное приложение теоретически можно закрыть, нажав на крестик (или красный кружочек, или что там ещё бывает). Тем не менее, менеджеры задач, позволяющие прибить зависшее приложение, весьма популярны.
                +4
                Да, и программы обычно в C:\Program Files ставятся, и обычный пользователь ничего не сможет сохранить в настройках.
                  +2
                  Но, вообще говоря, идея и техника использования многопоточных файлов интересны сами по себе.
                  Думаю, им есть более подходящие применения.
                    0
                    кто только не пробовал придумать им применения, и антивирусники даже (у Каспера такая функция была — он хранил данные о скане файла в альтернативном потоке)
                      0
                      ну к примеру FlylinkDC++ хранит TTH расшаренных файлов в потоках NTFS.
                      Удобная функция — сильно ускоряет повторное перехэширование файлов при перемещении их в другое место.
                    +4
                    Таким образом, можно держать несколько копий программ с разными настройками (причем, только тогда, когда программы в разных директориях).
                    можно передавать в параметрах запуска имя конфига.
                    эти файлы настроек как груз висят над душой.
                    не вижу ничего страшного в одном файле рядом с программой. Этот подход не обладает кучей минусов, как использование потоков, и при этом гораздо прозрачнее для пользователя. Плюс в случае, если программа даже не сможет стартовать с кривыми настройками, их легко можно будет потереть руками. Штатные средства венды ЕМНИП не умеют нормально работать с потоками.
                      +1
                      я бы хотел увидеть аргументы от несогласных. Не думал, что на хабре столько людей, которые сразу бегут какать в карму при виде комментария, не совпадающего с их личным мнением.
                      • НЛО прилетело и опубликовало эту надпись здесь
                    • НЛО прилетело и опубликовало эту надпись здесь
                        +2
                        Вот и да. Давайте уже делать как нибудь более стандартно, зоопарк — плохо.
                        0
                        Это писалось, как альтернатива, а не как призыв к действию. Мелких утилиты (у которых кстати файлы конфигураций могут быть одинаково названы) смогут жить в одном при спокойно себе в одной папочке, никому не мешая.
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Я бы посмотрел, как вы попытаетесь записать в запущенный экзешник что-либо.
                            • НЛО прилетело и опубликовало эту надпись здесь
                                –1
                                Я не говорю, что это не возможно… просто для того, что бы это реализовать, потребуется достаточно много усилий… А потом в один прекрасный момент «лавочку закроют» которая позволяла это реализовать. И придется придумывать что-нибудь другое.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                    –1
                                    Потому что это стандартная часть файловой системы. Которую Microsoft реализовала, для того, что бы обеспечить совместимость например с форматом файлов пользователей MAC. Кстати первая такая поддержка была еще в NT 3.1. И я думаю, что раз они это сделали специально. И до сих пор поддерживают, то пока есть NTFS, будут и потоки.
                              0
                              А вообще идея сначала была примерно такой же. Была программа у которой был один единственный настраиваемый параметр (bool). и не хотелось из-за такой мелочи таскать еще один файл с настройкой. Хотел изменять в самом файле тот байт, где хранится инициализирующее значение. Но увы.
                              +1
                              Против самой идеи ничего не имею, она хороша, как альтернатива. Зато имею против потоков. Не стоит их использовать, пока нет стандартных средств в ОС для работы с ними.
                                –1
                                Чем не стандарты habrahabr.ru/blogs/windows/46990/?
                                Единственное для получения списка потока приходится чуть чуть изворачиваться.
                                  0
                                  Я имел в виду средства, доступные обычным пользователям (через ГУИ), как ини-файлы и реестр.
                              +1
                              Реестра вам, значит, мало…
                              • НЛО прилетело и опубликовало эту надпись здесь
                                0
                                А если скопировать программу на флешку? Там ведь FAT/FAT32. Программа просто работать не будет. Или будет, но не сможет сохранять настройки.
                                  0
                                  Уже когда-то писал про это: habrahabr.ru/blogs/windows/46935/
                                  В том топике в комментариях разложили все по полочкам и выяснили, когда уместно пользоваться этими самыми потоками.
                                    +1
                                    Помнится во времена DOS встречал пару раз когда программа прописывала свои настройки в сам исполняемый файл — это получается гораздо переносимее, если уж так захотелось хранить всё вместе.

                                    И откуда такая уверенность, что ini находится исключительно вместе с программой, а не в профиле пользователя? ;-)

                                    «чтобы» и «небольшая» пишутся слитно (в твоём случае)
                                      +2
                                      А как же права доступа? У каждого пользователя свои настройки и они не должны быть доступны другим. Нормально это решается хранением их в домашней папке юзера.
                                        +1
                                        Я понимаю, название блога обязывает)
                                        Жопу чесать иногда легче через гланды.
                                          0
                                          Я встречал небольшие программы (с небольшим кол-вом настроек), которые хранили настройки прямо в имени исполняемого файла :) Что-то вроде «program_1_2_3.exe». Конечно, это были пустячковые утилиты для запуска вручную из папки. В NT системах можно изменять имя исполняемого файла прямо в процессе работы, конечно, если есть соответствующие права.

                                          Кстати, безумная идея — булевские переменные можно хранить в имени, фактически не влияя на него — достаточно изменять регистр одного из символов :)

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

                                          Самое читаемое