Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 286
Настойки — реестр. Временные и рабочие файлы — %TEMP%. Имхо здесь не нужно изобретать велосипед.
Microsoft настоятельно рекомендует отказаться от идей хранения настроек в реестре, оставив его (реестр) для системных и легаси-приложений, которые нет смысла переделывать на отказ от реестра (особенно в случае с COM)
То майкрософт рекомендует использовать реестр, то уже не рекомендует %)
Вы малёхо запоздали. Майкрософт перестал указывать на реестр году этак в 2002.
Да, ни на кого нельзя положиться в этом мире :)
Да, ни на кого нельзя положиться в этом мире :)
Это просто потому что давно на лунукс перешел :) вот по старой памяти вспомнилось, как по рекомендациях майкрософта учился в реестр писать :)
Реестр теперь остался только для системы. Почему бы им тогда систему не перевести на хранение настроек в файлах и не избавиться от реестра, если они его не рекомендуют?
Это было бы здорово.
А какая вам разница, как сделано в системе; работает — не трогай, вам разве мешает? :)
Нахрена переходить на хранение настроек системы в файлах?
Нахрена переходить на хранение настроек системы в файлах?
Совсем круто — это SQL-like хранилище с XML-конфигами внутри — легко искать, легко модифицировать. Мечты…
И заодно выкинуть возможность ставить старые программы?
С чего бы это? Разве «старые программы» работают с файлом реестра напрямую? Ведь через интерфейс же. Вот реализация и засовывала бы всё в фс.
Насколько я понимаю, от реестра рекомендуют отказаться не потому, что он не файловый, в противном случае можно было бы ничего не менять и сделать, как вы сказали.
Так что под «выкинуть» реестр я понял именно убирание того нежелательного реестра, чтобы в него нельзя было писать, а как именно он реализован, уже не суть.
Так что под «выкинуть» реестр я понял именно убирание того нежелательного реестра, чтобы в него нельзя было писать, а как именно он реализован, уже не суть.
Погодите, я может неправильно понял о чем вы… но реестр и так хранится в файлах. В нескольких. %SystemRoot%\System32\Config\ если не вдаваться в подробности.
Привет, gconf! :)
пруфлинк?
Млин, и за что человека минусуют? За просьбу пруфлинка? Минусуйте и меня, мне он тоже нужен: за все годы программирования я про это слышу впервые.
В MSDN написано обратное:
«The following are the initialization-file functions. They retrieve information from and copy information to a system- or application-defined initialization file. These functions are provided only for compatibility with 16-bit versions of Windows. New applications should use the registry.» (из Registry Functions).
В MSDN написано обратное:
«The following are the initialization-file functions. They retrieve information from and copy information to a system- or application-defined initialization file. These functions are provided only for compatibility with 16-bit versions of Windows. New applications should use the registry.» (из Registry Functions).
Цитата, что вы привели, из MSDN 99 года. Это раз. Второе — вы вырвали фразу из контекста, это нехорошо. В оригинале имелось в виду, что .INI файлы не рулят, и стоит использовать реестр (это и было его назначение).
С того времени все изменилось. Новое направление MS (.net) крайне не приветствует реестр — загляните в Beest Practices:
а) придерживаются политики Zero/XCopy Copy Deployment
б) манифестом файла (.manifest) можно полностью описать ту инфу, что раньше требовалась от реестра
в) в конфиг файлы приложения можно класть все настройки, что требовалось вносить в реестр. Местоположение файла также можно выбрать, чтобы не потерять при установке, например.
С того времени все изменилось. Новое направление MS (.net) крайне не приветствует реестр — загляните в Beest Practices:
а) придерживаются политики Zero/XCopy Copy Deployment
б) манифестом файла (.manifest) можно полностью описать ту инфу, что раньше требовалась от реестра
в) в конфиг файлы приложения можно класть все настройки, что требовалось вносить в реестр. Местоположение файла также можно выбрать, чтобы не потерять при установке, например.
А в чем проблема с реестром (по версии МS)?
Я не знаю, что по его поводу думает MS, но бывает много проблем с правами. Особенно тяжёлым был переход с XP на Висту. UAC — зло (хотя сейчас уже привыкли :)
UAC — зло, Вирусы — добро?
UAC не зло; зло те, кто решили, что их программа будет всегда работать под админом.
Windows, начиная с 2003 Server и Vista постепенно по модели безопасности начинает приближаться к Unix-системам, даже на домашних машинах. Чтобы старые программы не обломались в новой среде безопасности, и существует UAC.
Windows, начиная с 2003 Server и Vista постепенно по модели безопасности начинает приближаться к Unix-системам, даже на домашних машинах. Чтобы старые программы не обломались в новой среде безопасности, и существует UAC.
Поверьте, UAC создаёт значительно больше проблем, чем пользователи, работающие не под админами. Безусловно, раньше с нехваткой прав тоже были некоторые проблемы, но борьба с этими проблемами была тривиальной.
Каких проблем?
С удовольствием послушаю про проблемы (чур, elevation не приплетать, это отдельный решаемый вопрос).
Смотрите описание, напимер, первой проблемы поссылке.
Пример.
Есть подписанный msi. Ставим — всё ок. Начинаем удалять — UAC запрашивает разрешение, потому что считает, что с подписью что-то не так ( кажется, что-то с ней действительно случается при копировании в %SystemRoot%\installer ). Проблема пока решается только через одно известное всем место (городушкой городушек).
Пример.
Есть подписанный msi. Ставим — всё ок. Начинаем удалять — UAC запрашивает разрешение, потому что считает, что с подписью что-то не так ( кажется, что-то с ней действительно случается при копировании в %SystemRoot%\installer ). Проблема пока решается только через одно известное всем место (городушкой городушек).
Поверьте, UAC создаёт значительно больше проблем, чем пользователи, работающие не под админами.
Написал нам ботнет-зомби
Написал нам ботнет-зомби
Исходники sudo сколько лет валяются в инете, бери — не хочу…
В объеме — раз;
В правах — два;
В отсутствии удобных средств управления — три;
В неочевидности зависимостей и изменений — четыре;
В отсутствии самоописуемости — пять…
Продолжать?
В правах — два;
В отсутствии удобных средств управления — три;
В неочевидности зависимостей и изменений — четыре;
В отсутствии самоописуемости — пять…
Продолжать?
1. Надуманная проблема, не такие уж там объемы, чтобы говорить об этом.
2. С UAC никакой разницы нет что в User-директорию писать, что в CURRENT_USER реестра.
3. API для работы с реестром разве нет?
4. Можно подробнее?
5. Имеете ввиду, что комментарии нельзя написать для значений?
2. С UAC никакой разницы нет что в User-директорию писать, что в CURRENT_USER реестра.
3. API для работы с реестром разве нет?
4. Можно подробнее?
5. Имеете ввиду, что комментарии нельзя написать для значений?
1. Вы какой единицей меряете? Сотни тысяч записей, пусть и иерархических — это немного?
2. В плане прав нет. В плане контента ФС богаче по возможностям.
3. Есть, и что? Вы видели инстументы для удобной работы с ним — diff, упаковка, версии, все такое? Почему в нем остаются мегатонны лишних записей — API же есть?
4. Можно. Пропишите руками все ключи для регистрации out-of-process COM сервера и его же для DCOM. Затем поменяйте место его установки. Теперь тоже самое для Addin к Visual Studio, и при этом не ругаться матом :)
5. Нет, имею в виду, что совершенно непонятно, куда смотреть, чтобы найти настройки конкретной программы; а также непонятно, что эти настройки означают.
2. В плане прав нет. В плане контента ФС богаче по возможностям.
3. Есть, и что? Вы видели инстументы для удобной работы с ним — diff, упаковка, версии, все такое? Почему в нем остаются мегатонны лишних записей — API же есть?
4. Можно. Пропишите руками все ключи для регистрации out-of-process COM сервера и его же для DCOM. Затем поменяйте место его установки. Теперь тоже самое для Addin к Visual Studio, и при этом не ругаться матом :)
5. Нет, имею в виду, что совершенно непонятно, куда смотреть, чтобы найти настройки конкретной программы; а также непонятно, что эти настройки означают.
Вы, почему-то уверены в том, что основной юзкейс реестра, это ходить в него руками и что-то там править. Мне кажется, в идеологии Windows это совсем не так. Это просто хранилище для настроек программ. Следовательно работа с ним должна производиться средствами API.
Вот к примеру, есть у вас программа. При установке (мы знаем, что установка в основном проходит с повышенными правами) она может заполнить реестр каким-либо настройками в HKLM. Далее ей начинает пользоваться человек. Соотвественно все что он меняет пишется в HKCU. Таким образом при переносе профиля пользователя с одной машины на другую его HKCU переедет вместе с ним. И, если на другой машине эта программа установлена, то пользователь приятно удивится, потому что окружение программы будет настроено под него.
Реестр нельзя использовать для portable версий программ, так как они запускаются с ограниченными правами и скорее всего смогут писать только в свою или пользовательскую директорию (скорее всего они в ней и находятся). Замусоривать HKCU или User\Application Data смысла нет, так как в этом случае настройки не будут portable. :)
В целом, я хочу сказать, что если подчинить разработку архитектуре системы и знать ее особенности, то реестр очень удобен.
Вот к примеру, есть у вас программа. При установке (мы знаем, что установка в основном проходит с повышенными правами) она может заполнить реестр каким-либо настройками в HKLM. Далее ей начинает пользоваться человек. Соотвественно все что он меняет пишется в HKCU. Таким образом при переносе профиля пользователя с одной машины на другую его HKCU переедет вместе с ним. И, если на другой машине эта программа установлена, то пользователь приятно удивится, потому что окружение программы будет настроено под него.
Реестр нельзя использовать для portable версий программ, так как они запускаются с ограниченными правами и скорее всего смогут писать только в свою или пользовательскую директорию (скорее всего они в ней и находятся). Замусоривать HKCU или User\Application Data смысла нет, так как в этом случае настройки не будут portable. :)
В целом, я хочу сказать, что если подчинить разработку архитектуре системы и знать ее особенности, то реестр очень удобен.
>> что основной юзкейс реестра, это ходить в него руками и что-то там править
Если реестр позволяет это делать и так думать про него, более того — есть reg- и rgs- файлы, которыми можно патчить ветки реестра, то, мне кажется, это проблема реестра, а не моя — это он сделан таким образом, что позволяет думать про него так, а не иначе :)
В теории он превосходен — как раз проектировался для того, чтобы собрать многочисленные ini по всей системе в одно место. Опять же, заметьте — собрать ini системы и системных приложений, т.е. internal settings.
На практике после появления HKCU, а потом и public API к любым кустам, началась жесть :)
Если реестр позволяет это делать и так думать про него, более того — есть reg- и rgs- файлы, которыми можно патчить ветки реестра, то, мне кажется, это проблема реестра, а не моя — это он сделан таким образом, что позволяет думать про него так, а не иначе :)
В теории он превосходен — как раз проектировался для того, чтобы собрать многочисленные ini по всей системе в одно место. Опять же, заметьте — собрать ini системы и системных приложений, т.е. internal settings.
На практике после появления HKCU, а потом и public API к любым кустам, началась жесть :)
Заметьте, что реестр никак не мешает вам не лазить в него руками или каким-либо образом наводить там бардак.
Естественно, попав в руки массы программистов, которые не понимают, что такое проектирование и системный подход, и совершенно не знакомых с архитектрурой Windows, пал их жертвой. Началось бессмылсленное использование HKLM, HKCU и т.д. Но, вы наверняка знаете, про ресурс govnokod.ru. Ведь это же не проблема предствавленных там ЯП, что ими так пользуются?
Я вот сейчас смотрю на проблему конфигов в *nix, там все на файлах. Так вот проблем меньше от этого не становится, все конфиги в разных местах, разных форматов (в форматах просто феерия какая-то)
Естественно, попав в руки массы программистов, которые не понимают, что такое проектирование и системный подход, и совершенно не знакомых с архитектрурой Windows, пал их жертвой. Началось бессмылсленное использование HKLM, HKCU и т.д. Но, вы наверняка знаете, про ресурс govnokod.ru. Ведь это же не проблема предствавленных там ЯП, что ими так пользуются?
Я вот сейчас смотрю на проблему конфигов в *nix, там все на файлах. Так вот проблем меньше от этого не становится, все конфиги в разных местах, разных форматов (в форматах просто феерия какая-то)
Не обобщайте про *nix, в той же *BSD сто лет уже конфиги в одних и тех же местах, что нельзя сказать про linux, вот там как раз бардак.
Вы правы, погорячился, я могу только про Ubuntu и Debian говорить.
а пример можно? я что-то не помню конфигов вне /etc и /home/user (если софт правильно ставить)
Во-во. Вы сами его и привели :)
эм… /etc глобальные конфиги. /home/user — для каждого юзера отдельно. где бардак? зачем мне править /etc/wgetrc, если я могу править /home/user/.wgetrc
А, то есть это типа HKLM (/etc) и HKCU (/home/user)?
ну, строго говоря, в линуксе бардак всё-же есть, по крайней мере, кроме приведённых вами
/etc/
/home/user/
есть ещё
/home/user/.appdata/ #Adobe Air приложения
/home/user/.config/
/home/user/.gconf/
/home/user/.gnome2/
причём, например, папка file-roller есть и в /home/user/.gconf/, и в /home/user/.gnome2/
P.S. Неужели во FreeBSD не так устроено? Я честно не в курсе.
/etc/
/home/user/
есть ещё
/home/user/.appdata/ #Adobe Air приложения
/home/user/.config/
/home/user/.gconf/
/home/user/.gnome2/
причём, например, папка file-roller есть и в /home/user/.gconf/, и в /home/user/.gnome2/
P.S. Неужели во FreeBSD не так устроено? Я честно не в курсе.
Это бардак?
Реестр замусоривается и тяжело чиститься. Нет удобных инструментов, а в том же Ubuntu достаточно удалить каталог и нет проблем.
Реестр замусоривается и тяжело чиститься. Нет удобных инструментов, а в том же Ubuntu достаточно удалить каталог и нет проблем.
И что вам с этого бардака в реестре? Вы верите в миф что компьютер начинает медленнее работать?
Я не верю, я знаю ;)
А на линуксе вот уже три года все летает =)
А на линуксе вот уже три года все летает =)
дайте пруфлинк :) не верю я в то что виндовс начинает _ощутимо_ меленнее работать из-за того, что там 400 лишних значений записано.
«Чем дольше ваш компьютер работает без переустановки, тем сильнее разрастаются файлы реестра. Это одна из особенностей Windows и со временем она может привести к снижению производительности компьютера.»
support.microsoft.com/kb/835823/ru
support.microsoft.com/kb/835823/ru
реестр — он как энтропия — всегда растет ;-)
Тут не совсем понятно что именно растет.
Если речь идет о размере хранилища (ну файлы эти), то ничего страшного. Свободное место может использоваться повторно. Есть и дефрагментаторы реестра, которые позволяют повысить вероятность повторного использования.
Если речь о самом контенте то это кривизна (де)инсталяторов, и я не думаю что переход на ФС тут кардинально что-то меняет.
Если речь идет о размере хранилища (ну файлы эти), то ничего страшного. Свободное место может использоваться повторно. Есть и дефрагментаторы реестра, которые позволяют повысить вероятность повторного использования.
Если речь о самом контенте то это кривизна (де)инсталяторов, и я не думаю что переход на ФС тут кардинально что-то меняет.
Это 2004 год и
Информация в данной статье применима к:
* Microsoft Windows 98 Standard Edition
* Microsoft Windows 98 Second Edition
(с)
Тогда были совсем другие мощности. Не уверен, что сейчас энтропия реестра _ощутимо_ влияет на производительность.
Информация в данной статье применима к:
* Microsoft Windows 98 Standard Edition
* Microsoft Windows 98 Second Edition
(с)
Тогда были совсем другие мощности. Не уверен, что сейчас энтропия реестра _ощутимо_ влияет на производительность.
Ну есть же альтернативные редакторы реестра, в них, помнится, добавляли тонны плюшек. Вот вам и удобные инструменты.
Руками лезть в реестр? Зачем? Среднему программисту достаточно складывать настройки программы в (HKLU|HKLM)/Software/company/appname. Если нужны специальные случаи (напр. регистрация COM-объектов и т.п.) — есть спец интерфейсы и консольные утилиты.
Мне, как прикладному программисту, важно какое-нибудь хранилище для настроек. А как оно внутри организовано — это уже проблемы операционной системы и заботы других людей.
Руками лезть в реестр? Зачем? Среднему программисту достаточно складывать настройки программы в (HKLU|HKLM)/Software/company/appname. Если нужны специальные случаи (напр. регистрация COM-объектов и т.п.) — есть спец интерфейсы и консольные утилиты.
Мне, как прикладному программисту, важно какое-нибудь хранилище для настроек. А как оно внутри организовано — это уже проблемы операционной системы и заботы других людей.
Хотя думаю феерия форматов там ровно такая же.
Выше ответил. По поводу прав: предположим, есть программа. Почему-то падает с Security Exception. Есть подозрение на реестр. Вопрос — как настроить права?
Дык и для IT проблема Security Exception не большая проблема, есть же инструменты вроде Application Compatibility Toolkit, если не ошибаюсь — как раз для IT персонала (там анализ можно сделать куда лезет ПО) и создания «заплаток» + система перенаправления в UAC работает прозрачно… конечно, если ПО «правильное» (по мнению M$), то такого изврата не потребуется…
Вы это поймете сами, когда решите перенести настройки приложений на новый комп со свежепоставленнос ОС.
Если все настройки хранятся в AppData и им подобных, перенос сведется к копированию папок.
Если настройки хранятся в реестре, то вам придется долго бегать по HKCU и HKLM в поисках настроек своего приложения, затем экспортировать их в reg-file и исполнять этот рег-файл уже на новой машине.
Если все настройки хранятся в AppData и им подобных, перенос сведется к копированию папок.
Если настройки хранятся в реестре, то вам придется долго бегать по HKCU и HKLM в поисках настроек своего приложения, затем экспортировать их в reg-file и исполнять этот рег-файл уже на новой машине.
Систему переустанавливали хоть раз? Не замечали, что настройки сбрасываются на дефолтные.
А если в ФС хранится, то все настройки остаются ;)
А если в ФС хранится, то все настройки остаются ;)
Большей загадкой является то, зачем вообще надо было придумывать реестр, который по сути является ущербной файловой системой, и API для работы с ним — который по сути является ущербным интерфейсом для работы с ущербной файловой системой.
OLE, COM, ActiveX и иже с ними. Закончилось все былинным провалом, но теперь уже никуда не деться.
Ну OLE, COM, ActiveX живут и здравствуют, в чем провал-то? В той-же Win7 DirectX 11, Direct2D и новые GUI API — чистый COM.
И это всёравно не отменяет былинную кривость сиих технологий, особенно ActiveX
COM там только снаружи, для совместимости. Внутри уже давно не COM — по крайней мере, время жизни компонент управляется уже не по-комовски.
Как и в WinXP, как и в Win95… С чистым COM жить можно, но для многих задач он попросту слишком сложен. Даже встроенный reference counting не всегда нужен: для того же DirectX все равно обычно пишутся более удобные объектные обертки:)
Реестр не ФС, реестр — виртуальная иерархическая БД с разнородными по своей природе узлами — некоторые из них читаются из файлов, некоторые выставляются бутлоадером системы, некоторые — существуют только в памяти обеспечивающих их служб. API, соответственно, тоже далек от ФС.
Реестр вообще предполагался для использования исключительно внутри ОС. Ошибка то, что к нему появился public API.
Реестр вообще предполагался для использования исключительно внутри ОС. Ошибка то, что к нему появился public API.
Потому что он бысчтрее. чем чмтать и парсить тексоые файлы, как в юниксах. И формат хранения данных единообразный.
Я не понимаю почему вы говорите о конкретном положении в ФС, а о реестре как едином целом. Также не понимаю почему упоминают о проблеме прав на запись в реестр в целом, а в ФС рассматривают различные размещения. Реестр так же как и ФС поддерживает индивидуальные права для различных размещений. Есть HKCU же.
И заодно по содержимому поста: это неправильно, указывать пути для различных папок пользователя в конкретных ОС. Их нужно получать апи-средствами во время работы программы (или читать из переменных окружения, что не так «чисто», но может оказаться более гибким для админа)
И заодно по содержимому поста: это неправильно, указывать пути для различных папок пользователя в конкретных ОС. Их нужно получать апи-средствами во время работы программы (или читать из переменных окружения, что не так «чисто», но может оказаться более гибким для админа)
всегда удивляло стремление многих программ хранить свои данные в папке «My Documents», иногда в этом есть смысл, но когда игры свои севы там хранят, или программы конфиги…
в общем то это наверняка одна из причин почему многие этой папкой пользоваться перестали
в общем то это наверняка одна из причин почему многие этой папкой пользоваться перестали
С одной стороны не логично, с другой уже который год переустанавливая систему я не волнуюсь о сохранности моих колоний в Age Of Empires.
*не в теме* А разве винду нельзя переустановить, не затрагивая My Documents?
Вообще-то можно. Надо с помощю какого-то там (не помню) твикера (или же в реестре) задать путь к папке Мои Документы. Но после переустановки надо снова ковырятся в настройках. Монтирования, такого как в линуксе, к сожалению нет.
П.С. Это снова по старой памяти, счас не знаю как.
П.С. Это снова по старой памяти, счас не знаю как.
Во блин, а я так привык носить /home не отдельной партиции…
Вы извращенец. В свойствах Моих документов можно указать любую папку для них.
гыг, а некоторые софтописатели, не пользуются относительными путями, то есть пользуются, но для сохранения чего нить используют переменную не %mydocuments%, а %user%/mydocuments
(точно как пишуться переменные влом вспоминать) и результат получается ахрененый :)
(точно как пишуться переменные влом вспоминать) и результат получается ахрененый :)
Ну извиняюсь… Когда я этой виндой пользовался… Не припомню…
+ В реестре можно почти все пути системных папок менять здесь:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
И это тоже (как реестр) устарело нехило :). Задать расположение всех пользовательских папок начиная с висты можно просто в свойствах этой папки. Кроме того в висте же появился папка для сейвов в профиле пользователя
Монтирование разделов (томов) в папки NTFS было, наверное, всегда :)
Я обычно монтирую все свои диски в папки на диске С: — удобно, да ещё и вкупе с симлинками можно как хочешь сконфигурировать файловую структуру
Я обычно монтирую все свои диски в папки на диске С: — удобно, да ещё и вкупе с симлинками можно как хочешь сконфигурировать файловую структуру
Я вобще-то сказал что так и делаю, потому и рад, что некоторые игры хранят настройки в Моих документах.
User\Application Data
лично я при переустановке винды, сохраняю всю папку юзер, а не только майдокументс… потом все что нужно из нее копирую в новую систему, а так я повторяю, из-за подобных софтописателей, функционал папки майдокументс стремится к нулю…
лично я при переустановке винды, сохраняю всю папку юзер, а не только майдокументс… потом все что нужно из нее копирую в новую систему, а так я повторяю, из-за подобных софтописателей, функционал папки майдокументс стремится к нулю…
может потому что она находится на системном разделе, который нередко форматится при переустановке винды. проще все хранить на диске Д
User\Application Data всегда открыт для записи, даже если у пользователя самые минимальные права, так что с этим местом не прогадаете точно. Хотя «по-джентльменски» (чтобы не мусорить) лучше хранить всё в директории с программой, заодно она ещё и портабольной будет.
Как раз-таки в директории с программой и не будет портабельности — если отключена UAC>виртуализация директорий, то программа будет тупо падать при запуске не из-под админа.
… заодно пользователь будет UAC отключать чтоб програмка работала. ну-ну
С портаблой я поступаю проще, программа ищет в своей директории файл с именем portable и, если находит его, сохраняет свои настройки в папке программы, если не находит — работает с Application Data.
~/.program_name
Согласен :)
Воистину. А все вот эти метания «где хранить» — исключительно из-за отсутствия нормальной организации структуры каталогов в винде, что есть, ИМХО, совсем плохо.
Ставить надо в /usr/local, внешние диски, ествественно в /media.
угу, угу. а если надо ставить программы не как администратору (игрушки там)? у коммерческих хотя бы есть инсталляторы.
репозитории — хорошо. но иногда хочется, чтобы можно было поставить софтину из репозитория в ~/ а не в систему. кто знает что из существующего такое умеет подскажите :)
репозитории — хорошо. но иногда хочется, чтобы можно было поставить софтину из репозитория в ~/ а не в систему. кто знает что из существующего такое умеет подскажите :)
Если ставлю софт которого нет в портажах использую /opt, чтобы потом проще было удалять.
Т.к. предпочитаю монтировать руками — использую /mnt постаринке.
А куда портаж ставит софт… ну тут по разному все зависит от того что за пакет.
Т.к. предпочитаю монтировать руками — использую /mnt постаринке.
А куда портаж ставит софт… ну тут по разному все зависит от того что за пакет.
Пакеты сами распихивают свои исполняемые файлы в /usr/bin(большая часть софта), /bin (то, что можно назвать стандартным (системным) софтом) или /usr/sbin (/sbin)(софт, для работы из-под root`а). Некоторый проприетарный софт ставится в /opt (как правило самим пользователем), туда же могут ставятся пакеты от других дистрибутивов, самосбор чаще всего в /usr/local/bin. Пара-тройка вещей в домашний каталог, win-софт в ~/.wine.
Диски в /mnt. Флэшки-камеры в /media.
Диски в /mnt. Флэшки-камеры в /media.
Да нормальная структура каталогов в винде. А эти метания — просто попытки изобрести собственный велосипед и нежелание читать документацию.
~/.config/program_name, имхо посимпатичнее вариант :)
а потом засранный /home/username. я привык к mc и листать эту кучу ~/.programname иногда долго приходится
скорее что-то типа ~/.appsettings/.programname некоторые так и поступают
скорее что-то типа ~/.appsettings/.programname некоторые так и поступают
По дефолту файлы с. скрыты или вы под рутом кучу приложений ставите?
скрыты если смотреть через ls и через графические приблуды. mc все показывает и это правильно.
Ну я не пользуюсь mc, поэтому не в курсе. Но что-то мне подсказывает, что можно скрыть.
В ls можно увидеть дав ключик -a
$ ls -la
Настройки -> конфигурация -> убрать галочку «Показывать скрытые файлы».
Вообще я тоже сейчас немного удивился вашему комментарию — в Debian'e по умолчанию для всех пользователей кроме root этой галочки нет. В убунте сейчас посмотрел — стоит по дефолту.
Вообще я тоже сейчас немного удивился вашему комментарию — в Debian'e по умолчанию для всех пользователей кроме root этой галочки нет. В убунте сейчас посмотрел — стоит по дефолту.
Мне тоже *nix концепция больше нравится.
~/App_Data :)
Считаю, что установщик должен давать возможность выбирать место хранения настроек программы.
А где хранить место, где хранятся настройки?
Полагаю, в папке с самой программой. Я плохо в этом разбираюсь, но, думаю, создать при установке файл с этой настройкой проблемой не будет. Впрочем, эту настройку даже не обязательно где-то хранить: программа может просто по очереди проверять возможные места.
А за что минусуют-то, кстати?
Установка софта в Program Files идёт всё равно только из-под администратора, так что самый главный readonly ini-файл логично класть в папку программы (программе будет очень просто найти его независимо от версии ОС), а в нём уже прописать все глобальные настройки, вообще, и, где будут хранить свои настройки пользователи, и будут ли эти пользователи, или настройки глобальные для всего компа и т.п., в частности.
Если же устанавливаешь программу обычным юзером, то, опять-таки, имеешь полный доступ к папке программы.
Что-то типа:
Установка софта в Program Files идёт всё равно только из-под администратора, так что самый главный readonly ini-файл логично класть в папку программы (программе будет очень просто найти его независимо от версии ОС), а в нём уже прописать все глобальные настройки, вообще, и, где будут хранить свои настройки пользователи, и будут ли эти пользователи, или настройки глобальные для всего компа и т.п., в частности.
Если же устанавливаешь программу обычным юзером, то, опять-таки, имеешь полный доступ к папке программы.
Что-то типа:
main.ini[usersettings]
;storage = registry
storage = file
dir = %appdata%/my_mega_app
В реестре. Уж один то ключик потянет эта бд.
Значит такая штука, есть system wide настройки и пользовательские. Грубо говоря system wide настройки применяются ко всем профилям, а юзерские лишь к конкретному, причем пользовательские имеют более высокий приоритет.
Реестр для хранения настроек мягко говоря не слишком хорошо подходит, есть проблемы с его чисткой, нужны админские права на запись туда, да и вообще штука не слишком удачная, ибо очень хрупкая и совсем неудобная для редактирования. Поэтому system wide настройки нада хранить в ProgramData (или как там эта папка в современных виндах называется) или на худой конец в Program Files, что не является хорошей идеей.
И ещё очень полезна возможность делать portable сборку проги, когда она хранит все настройки в папке с программой.
Реестр для хранения настроек мягко говоря не слишком хорошо подходит, есть проблемы с его чисткой, нужны админские права на запись туда, да и вообще штука не слишком удачная, ибо очень хрупкая и совсем неудобная для редактирования. Поэтому system wide настройки нада хранить в ProgramData (или как там эта папка в современных виндах называется) или на худой конец в Program Files, что не является хорошей идеей.
И ещё очень полезна возможность делать portable сборку проги, когда она хранит все настройки в папке с программой.
Про system wide это как раз последний пункт в статье. Про портативную версию я написал в комментарии выше, наверное проще создавать файл, находя который, программа будет работать в портативном режиме.
Плюсы очевидны: не нужно делать отдельную сборку, пользователь сможет сам сделать из установленной программы портативную версию скопировав файлы в отдельную папку и создав в папке программы файл portable
Плюсы очевидны: не нужно делать отдельную сборку, пользователь сможет сам сделать из установленной программы портативную версию скопировав файлы в отдельную папку и создав в папке программы файл portable
А мы так и делаем, ежели прога находит рядом со своим бинарником папку config, то пишет туда, плюс она будет искать конфиги в папках ../share /usr/share, и так далее… (насчет путей для винды я не определился ещё).
Эти настройки являются так называемыми fallback настройками, ну или дефолтными, сделано это таким образом, чтобы проще было в готовой сборке дефолты изменять.
Эти настройки являются так называемыми fallback настройками, ну или дефолтными, сделано это таким образом, чтобы проще было в готовой сборке дефолты изменять.
Для записи в ветку HKCU не нужны права админа в системе. Поэтому пользовательские настройки можно хранить и там
Еще изредка бывает необходимость иметь несколько версий одной и той же программы (например веб-разрботчику). Соответственно общие настройки могут мешать в случае несовместимости этих самых настроек, к примеру банально разных путей для плугинов.
В этом плане понравилась возможность выбора, где хранить, у оперы в инсталлере.
В этом плане понравилась возможность выбора, где хранить, у оперы в инсталлере.
~/Library/Application Support/App Name — рабочие файлы программы
~/Library/Preferences — настройки
Смешные проблемы у вин программеров :)
~/Library/Preferences — настройки
Смешные проблемы у вин программеров :)
Дык
~/.config/app
~/.local/config/app
/usr/share/config/app (для неизменяемых дефолтов)
В общем опять же всё от того, что в винде кто во что горазд всё делает, от того и проблемы
~/.config/app
~/.local/config/app
/usr/share/config/app (для неизменяемых дефолтов)
В общем опять же всё от того, что в винде кто во что горазд всё делает, от того и проблемы
Макось детектед.
Моя мечта — когда все программы хранят все барахло нужное им для работы у себя в папке (аля portable)
Но я понимаю, что это удобно лично мне, и не соответствует идеологии совместного использования компьютера :)
Но я понимаю, что это удобно лично мне, и не соответствует идеологии совместного использования компьютера :)
Не только вам. Это ещё страсть как удобно вирусне.
а я вообще не понимал почему все программы не хранят у себя в папке свои настройки, а только сейчас вспомнил что на компах часто по несколько пользователей (
а так постоянно стараюсь портейбл юзать. Или установить винду, понаставить всяких программ на отдельный диск и винду переустановить) многие будут продолжать работать, хотя связи с системой уже практически не будет
а так постоянно стараюсь портейбл юзать. Или установить винду, понаставить всяких программ на отдельный диск и винду переустановить) многие будут продолжать работать, хотя связи с системой уже практически не будет
Уважаю программы, которые дают сделать выбор — где хранить настройки. И не бьются в панике после переустановки системы
я уважаю программы которые дают право выбора вообще) а то есть некоторые программы которые без настроек практически а если и есть настройки то на уровне начинающего пользователя. ну понятно что заботятся о нубах которым пофиг на это, главное чтобы работало, но и о нас не надо забывать >_<
Это ведёт к страшному зоопарку и засумориванию. Выбор места хранения может быть полезен для пользовательских данных, навроде игровых сейвов, а для выбора папки хранения конфигов должен быть общесистемный способ указывать куда конфиги писать, ну или например как в Никсах возможность на отдельном разделе хранить всё это дело без граблей
А не уважаю _прикладные_ программы, которые вообще имеют какие-то настройки. Самое больше, что я готов простить — это «Укажите папку, которую надо просканировать для (вставьте по вкусу)».
вообще-то у всех современных фреймворках для разработки десктопного ПО есть стандартный API для хранения, использования и редактирования настроек. Так вот его и нужно использовать
Иной раз бывает потребность в написании своего, причем обязательно с B&H.
Именно. В .net это Isolated Storage. Проблема в том, что в Isolated Storage необходимо указывать scope. Так что проблема выбора папки превращается в проблему выбора скоупа, а не решается :(
А можно узнать подробней про стандарты хранения настроек.
Какие вообще существуют, где можно посмотреть?
Какие вообще существуют, где можно посмотреть?
Эх, если бы все так и делали…
Не раз терял какие-либо настроечные файлы или сохранения игр после переустановки системы из-за того, что каждая программа сохраняет настройки там где ей вздумается.
Не раз терял какие-либо настроечные файлы или сохранения игр после переустановки системы из-за того, что каждая программа сохраняет настройки там где ей вздумается.
Program Files
Хранить настройки в папке самой программы не рекомендуется, пользователю банально может просто не хватить прав на запись и чтение каталога программы. Плюс (вернее минус) настройки пользователей будут разделяемыми, никто не сможет настроить программу под себя или хранить в ней только персональные данные.
А еще за такое программерам надо отрубать руки…
Иногда — да, иногда — нет.
Я, например, сто лет назад uTorrent поставил, конфиги храню рядом, в этой же папке, торент-файлы тут же, в отдельной папке внутри.
Подобные программы ложатся не в Program Files а в Programs и при переустановке перемещаются простым копированием.
Очень удобно.
Но это дома, мой компьютер, с которым «чё хочу — то ворочу», а это многое меняет.
Я, например, сто лет назад uTorrent поставил, конфиги храню рядом, в этой же папке, торент-файлы тут же, в отдельной папке внутри.
Подобные программы ложатся не в Program Files а в Programs и при переустановке перемещаются простым копированием.
Очень удобно.
Но это дома, мой компьютер, с которым «чё хочу — то ворочу», а это многое меняет.
Больше чтения официальных гайдов — меньше велосипедов, все уже давно за вас продумано.
Указали бы в статье системные переменные указывающие на эти папки. А то ктото еще кинется проверять версию винды и формировать абсолютные пути :)
Чем-то напоминает на гайдлайны у эппла.
о как меня замучали эти настройки вечно пропадающие. впечь реесты. впечь аппликейшн даты. сжэчь!
после поднятия венды, снова всё настраивать дико раздражает (бывает что-то пропустишь или не досмотришь), так что в последнее время я за портабле, где всё хранится постаринке — в папке с прогой и никаких многоюзерских изъёбств!
после поднятия венды, снова всё настраивать дико раздражает (бывает что-то пропустишь или не досмотришь), так что в последнее время я за портабле, где всё хранится постаринке — в папке с прогой и никаких многоюзерских изъёбств!
> всё хранится постаринке — в папке с прогой и никаких многоюзерских изъёбств!
> после поднятия венды, снова всё настраивать дико раздражает (бывает что-то пропустишь или не досмотришь)
Может просто перестать ссать против ветра, не придется дико раздражаться оттого, что всегда мокрый? ;)
> после поднятия венды, снова всё настраивать дико раздражает (бывает что-то пропустишь или не досмотришь)
Может просто перестать ссать против ветра, не придется дико раздражаться оттого, что всегда мокрый? ;)
Средство переноса файлов не помогло?
Можно делать так, что если в папке с программой есть файл конфига, то настройки хранятся там, если там этого файла нет, то в User\Application Data.
По умолчанию хранить в User\Application Data, но если у пользователя достаточно прав, то он легко сделает прогу портабельной, скопировав оттуда настройки в папку с программой.
По умолчанию хранить в User\Application Data, но если у пользователя достаточно прав, то он легко сделает прогу портабельной, скопировав оттуда настройки в папку с программой.
/usr/share/%programname% или /etc/%programname%/
Hail грабли!!!
Настройки в /usr/share/ ???
www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA
www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA
My Documents — %USERPROFILE%\My documents
да да, вот про это выше я и говорю, жуть! руки за подобный метод поиска папки Мои документы отрывать, ее можно между прочим тоже положить в другое место, в папку на другом диске никак не привязанной к папке юзерпрофиль ;)
да да, вот про это выше я и говорю, жуть! руки за подобный метод поиска папки Мои документы отрывать, ее можно между прочим тоже положить в другое место, в папку на другом диске никак не привязанной к папке юзерпрофиль ;)
А на русской винде My Documents — это %USERPROFILE%\Мои документы
Надо использовать спецфункции для получения нужного пути навроде SHGetFolderPath().
Надо использовать спецфункции для получения нужного пути навроде SHGetFolderPath().
В испанской версии:
My Documents — %USERPROFILE%\Mis documentos
Application Data — Datos de Programa
My Documents — %USERPROFILE%\Mis documentos
Application Data — Datos de Programa
лучше всё хранить в папке программы.
чтоб потом было проще сделать портируемую версию.
да и если пользователь ставит программу не на диск C, то при переустановке системы придётся ставить заново, т.к. настройка «ушла».
чтоб потом было проще сделать портируемую версию.
да и если пользователь ставит программу не на диск C, то при переустановке системы придётся ставить заново, т.к. настройка «ушла».
Грабли
ваше мнение.
я десктопные приложения не пишу, чисто как пользователь говорю.
я десктопные приложения не пишу, чисто как пользователь говорю.
а если два пользователя на компьютере с разными настройками, то что делать?
а если работать не под админом то как? :) (ну это выше все озвучено)
а если работать не под админом то как? :) (ну это выше все озвучено)
Вынуть руки из одного места и почитать доки, а под админом работать это моветон, хвалите Балмера, что для винды нету удобного порта «программы из одной строчки на Perl»
ну у меня до сих пор XP, админские права, так что не особо над этим задумываюсь.
а вот переустанавливать систему приходится регулярно.
по-моему, нужно дать возможность пользователю выбрать.
и в том числе директорию с программой.
а вот переустанавливать систему приходится регулярно.
по-моему, нужно дать возможность пользователю выбрать.
и в том числе директорию с программой.
XP, админские права=>
переустанавливать систему приходится регулярно
))
да нет.
раз в полгода (ну в экстренном случае раз в 3 месяца).
просто софта много, времени мало.
лень опять же.
и поэтому на личном опыте убеждаюсь, что чаще пользуюсь программами, которые могут нормально работать без установки.
да нет.
раз в полгода (ну в экстренном случае раз в 3 месяца).
просто софта много, времени мало.
лень опять же.
и поэтому на личном опыте убеждаюсь, что чаще пользуюсь программами, которые могут нормально работать без установки.
Во во, сами блин срач привыкли разводить, а теперь ноете
у меня как правило, переставлять приходится именно из-за софта, а не из-за кривых рук.
Неееет… у меня даже антивируса нет установленного.
если что подозрительное — в виртуалке/ в sandboxie…
как-то выработался опыт работы, что не лажу, где попало, опера перенесит все напасти левых сайтов спокойной, херни не гружу, типа «кодеков» и «антивирусов», программы только из офиц.источника, комментарии к ней тоже люблю пару посмотреть.
И переустанавливаю не чаще раза в год — просто от того, что накаплывается мусор, левые библиотеки от ставших ненужными программ, написанными дураками, которые не могли сделать ее полностью удаляемой, и остатки мусора, которая винда создает для установщиков, мусора в тех самых app data и прочая, которые программы, работающие без установки, создают.
Бывают, правда, мои эксперименты с системными файлами — типа там ресурсы менять и если система не запускается после моих действий — вперед за live cd… но это уже другое)
если что подозрительное — в виртуалке/ в sandboxie…
как-то выработался опыт работы, что не лажу, где попало, опера перенесит все напасти левых сайтов спокойной, херни не гружу, типа «кодеков» и «антивирусов», программы только из офиц.источника, комментарии к ней тоже люблю пару посмотреть.
И переустанавливаю не чаще раза в год — просто от того, что накаплывается мусор, левые библиотеки от ставших ненужными программ, написанными дураками, которые не могли сделать ее полностью удаляемой, и остатки мусора, которая винда создает для установщиков, мусора в тех самых app data и прочая, которые программы, работающие без установки, создают.
Бывают, правда, мои эксперименты с системными файлами — типа там ресурсы менять и если система не запускается после моих действий — вперед за live cd… но это уже другое)
Друзья, задаю вопрос, который меня мучает уже много лет :)
Поясните, пожалуйста, в чем преимущество хранения настроек в реестре вместо кофигурационного файла? Особенно это касается небольших программ, коих на компьютерах подавляющее большинство, но они все равно в основном хранят свои настройки в реестре.
Поясните, пожалуйста, в чем преимущество хранения настроек в реестре вместо кофигурационного файла? Особенно это касается небольших программ, коих на компьютерах подавляющее большинство, но они все равно в основном хранят свои настройки в реестре.
1. Но нет гибкости в выборе как хранить специфические настройки
2. Но перечитать-то программе все равно придется значения? Не думаю что хоть кто-то из разработчиков предусматривает такой вариант развития — это скорее баг ;-)
3. Ну, для ini есть «API» не хуже. И я бы не назвал это «легко».
4. Только «сохранятся» все настройки всех программ. И что потом с этим (кстати, не маленьким) файлом делать? Сдается мне, если им (уж не знаю как) заменить текущий файл, то винда ляжет сразу же.
5. Я не специалист, но сдается мне, что винда через полгода активного установки/удаления программ начинает тормозить именно из-за замусоренного реестра ибо (имхо — поправьте) реестр грузится в память.
2. Но перечитать-то программе все равно придется значения? Не думаю что хоть кто-то из разработчиков предусматривает такой вариант развития — это скорее баг ;-)
3. Ну, для ini есть «API» не хуже. И я бы не назвал это «легко».
4. Только «сохранятся» все настройки всех программ. И что потом с этим (кстати, не маленьким) файлом делать? Сдается мне, если им (уж не знаю как) заменить текущий файл, то винда ляжет сразу же.
5. Я не специалист, но сдается мне, что винда через полгода активного установки/удаления программ начинает тормозить именно из-за замусоренного реестра ибо (имхо — поправьте) реестр грузится в память.
— Всевозможны парсеры распространенные уже написаны.
— Сомнительное преимущество — программа также может перечитывать файл…
— Парсер тоже разнообразен))
— И кучу мусора притянуть…
— Сомнительное преимущество — программа также может перечитывать файл…
— Парсер тоже разнообразен))
— И кучу мусора притянуть…
по-моему, первый пункт весьма спорный, т.к. CSV, JSON, и прочее-прочее…
Согласен. Можно многопоточно/из разных приложений читать-писать в поле в реестре с меньшими проблемами, чем с файлом ФС.
Насчёт NTUSER.DAT — спасибо, не знал.
Насчёт NTUSER.DAT — спасибо, не знал.
> Не нужно писать парсер конфигурационного файла
В WinAPI есть функции для работы с ini файлами, так что писать парсер для конфига средней сложности не нужно
В WinAPI есть функции для работы с ini файлами, так что писать парсер для конфига средней сложности не нужно
На конфетных осях — в NSUserDefaults
Можно было бы хотя бы добавть в рассмотрение вариант «Папка программы»
С точки зрения пользователя — программы могут хранить свои настройки где угодно, но, блин, не в «Моих документах».
Благодаря такой тенденции у многих программ, давно не пользуюсь этой папкой по назначению, отдав ее на съедение Windows и приложениям. А сами, собственно, документы, хранятся в D:\Documents
Вообще, огорчает навязывание системой/программами своей иерархии каталогизации данных пользователю.
Скажем, мне удобно хранить образы дисков в папке D:\ISO
Тем не менее, UltraISO, которой я создаю/редактирую образы, с маниакальным упорством создает папку My ISO Files в папке «Мои документы».
То же самое делает VMWare («My Virtual Machines»), хотя мне удобно хранить образы виртуальных операционных систем в D:\Virtuals и так далее.
В результате, при открытии «Мои документы» там обнаруживается куча папок, которых ты не заказывал, мало того, после удаления они создаются снова, при каждом запуске той или иной программы.
Конечно, мой алгоритм хранения и каталогизации данных покажется кому-то неудобным, кому-то извращенным и так далее. Но это мой компьютер, мои данные, и мне так удобнее и быстрее с ними работать. Очень жаль, что разработчики многих программных продуктов этого не понимают и пытаются навязать пользователю свою иерархию и классификацию, которая, возможно, удобна им, но не мне.
Благодаря такой тенденции у многих программ, давно не пользуюсь этой папкой по назначению, отдав ее на съедение Windows и приложениям. А сами, собственно, документы, хранятся в D:\Documents
Вообще, огорчает навязывание системой/программами своей иерархии каталогизации данных пользователю.
Скажем, мне удобно хранить образы дисков в папке D:\ISO
Тем не менее, UltraISO, которой я создаю/редактирую образы, с маниакальным упорством создает папку My ISO Files в папке «Мои документы».
То же самое делает VMWare («My Virtual Machines»), хотя мне удобно хранить образы виртуальных операционных систем в D:\Virtuals и так далее.
В результате, при открытии «Мои документы» там обнаруживается куча папок, которых ты не заказывал, мало того, после удаления они создаются снова, при каждом запуске той или иной программы.
Конечно, мой алгоритм хранения и каталогизации данных покажется кому-то неудобным, кому-то извращенным и так далее. Но это мой компьютер, мои данные, и мне так удобнее и быстрее с ними работать. Очень жаль, что разработчики многих программных продуктов этого не понимают и пытаются навязать пользователю свою иерархию и классификацию, которая, возможно, удобна им, но не мне.
Вообще My Documents это неудачная и кривая попытка воспроизвести /home в Линуксе и /Users (или как то по другому, непомню точного названия) в Макоси
Суть же первозданной идеи была в том, чтобы была домашняя папка пользователя с его личными данными, настройками и чем угодно, а не срач где попало, помимо этого срачу способствует доставшаяся с доса система именования дисков, разделов и проблемы с утилитами навроде mountvol, позволяющие как и везде смонтировать раздел в виде папки.
Суть же первозданной идеи была в том, чтобы была домашняя папка пользователя с его личными данными, настройками и чем угодно, а не срач где попало, помимо этого срачу способствует доставшаяся с доса система именования дисков, разделов и проблемы с утилитами навроде mountvol, позволяющие как и везде смонтировать раздел в виде папки.
Ключевая ошибка видна еще с названия корневой папки для всего этого безобразия: Documents AND Settigns.
Documents нужно таки отдельно, а Settings — отдельно, я считаю :)
Documents нужно таки отдельно, а Settings — отдельно, я считаю :)
Вообще-то суть «Моих документов» — это _дефолтная_ папка начинающего пользователя. Что бы он не спрашивал на разных компах, куда сохранился/сохранится его doc-файл. А не спрашивал: «что это за папка с названием моей любимой игры в окне выбора моих вордовых файлов»?
Единственный плюс выбора «My documents» в том, что в Win95/98 уже есть API-функция для определения этого пути, в отличие от функции для получении пути «Application Data».
Единственный плюс выбора «My documents» в том, что в Win95/98 уже есть API-функция для определения этого пути, в отличие от функции для получении пути «Application Data».
У меня стоит испанская XP и директории называются соответственно:
Archivos de Programa
Mis documentos
Datos de Programa
есть две папки: Configuración Local (с акцентом), где хранят данные все нормальные программы а также Configuracion Local (без акцента), куда предпочитает сбрасывает IE и Thunderbird (видимо UTF еще не все понимают)
Вместе с тем другие каталоги называются по-английски:
Documents and Settings
All Users
Local Service
Также имеется
User\Configuración Local\Application Data
User\Configuración Local\Datos de Programa
Помимо того, что в MS локализировали через пень-колоду, разработчики тупо верят, что во всем мире все папки будут называться как у них на компьютере.
Реально же названия фолдеров нужно брать отсюда:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders (большое спасибо MS!). Например для получения имени папки «Мои документы» можно использовать команду:
reg query «HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders» /v personal
Hint: некоторые из этих фолдеров прописаны в переменных окружения, но не все.
Archivos de Programa
Mis documentos
Datos de Programa
есть две папки: Configuración Local (с акцентом), где хранят данные все нормальные программы а также Configuracion Local (без акцента), куда предпочитает сбрасывает IE и Thunderbird (видимо UTF еще не все понимают)
Вместе с тем другие каталоги называются по-английски:
Documents and Settings
All Users
Local Service
Также имеется
User\Configuración Local\Application Data
User\Configuración Local\Datos de Programa
Помимо того, что в MS локализировали через пень-колоду, разработчики тупо верят, что во всем мире все папки будут называться как у них на компьютере.
Реально же названия фолдеров нужно брать отсюда:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders (большое спасибо MS!). Например для получения имени папки «Мои документы» можно использовать команду:
reg query «HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders» /v personal
Hint: некоторые из этих фолдеров прописаны в переменных окружения, но не все.
Для меня, как любителя портативных программ, конечно, лучше, если программа хранит все в своей папке… Жуть, как не люблю (хотя и редко делаю) переносить ключи из реестра, копаться в app data…
Грустно то, что изначально не продуманы пути хранения настроек…
даже с app data, localsett было намудрено…
куда проще было бы сделать
users/user/Settings/ — переносимые…
users/Temp/user/ — временные файлы и прочая…
Грустно то, что изначально не продуманы пути хранения настроек…
даже с app data, localsett было намудрено…
куда проще было бы сделать
users/user/Settings/ — переносимые…
users/Temp/user/ — временные файлы и прочая…
Ага, если бы ещё все хранили их одинаково. Лично я предпочитаю программы, которые хранят настройки в своей папке. И меня жутко бесит помойка в с:\users\%username%. Какая разница-то? Раньше была помойка в реестре, теперь на диске… MS-DOS рулит…
Отвечу как пользователь:
— Очень люблю программы, которые могут работать автономно. То есть ее поставил в каталог на несистемном диске, переставил ОС, а программа работает. Файл настроек пусть лежит рядом с самим exe файлом — мой ответ.
— Если же ваша программа требует инсталляции с добавлением dll в OS и после установки системы прекращает работать, то храните где хотите, НО мне нафиг не впали каталоги какой-то программы в моих документах, если они не содержат документов полезных мне как пользователю.
— Очень люблю программы, которые могут работать автономно. То есть ее поставил в каталог на несистемном диске, переставил ОС, а программа работает. Файл настроек пусть лежит рядом с самим exe файлом — мой ответ.
— Если же ваша программа требует инсталляции с добавлением dll в OS и после установки системы прекращает работать, то храните где хотите, НО мне нафиг не впали каталоги какой-то программы в моих документах, если они не содержат документов полезных мне как пользователю.
Очень инересно было бы хранить все настройки в Интернете.
Тоесть, есть у пользователя логин-пароль, он устанавливает на машину некоего демона, авторизует его, и он начинает подхватывать сохраняемые настройки(от поддерживаемых программ) и бекапить их на сервер. При такой реализации проблема перестановки винды отпадает сама собой, да и можно настройки синхронизовывать на нескольких компьютерах.
А если по сабжу — %APPDATA% конечно.
Тоесть, есть у пользователя логин-пароль, он устанавливает на машину некоего демона, авторизует его, и он начинает подхватывать сохраняемые настройки(от поддерживаемых программ) и бекапить их на сервер. При такой реализации проблема перестановки винды отпадает сама собой, да и можно настройки синхронизовывать на нескольких компьютерах.
А если по сабжу — %APPDATA% конечно.
На мой взгляд самый удобный вариант — разрешить пользователю выбирать. Будет достаточно двух пунктов:
1) хранить в каталоге самой программы (e.g. — Настройки программы едины для всех пользователей этого компьютера)
2) хранить в каталоге пользователя — это уже пусть сами программисты решают что за каталог (e.g. — Настройки программы различаются для каждого пользователя).
Вообще сам являюсь поклонником /home, /etc всего что с ними связано) Мне кажется логичным строгое разграничение того, куда какие файлы программы складывать. Например при переустановке ОС — необязательно копировать все программы. Программы можно поставить и ручками. А вот возможность скопировать все настройки всех приложений (без поиска этих настроек по всем системным каталогам, размазанным тонким и редким слоем по жёсткому диску) — очень удобна.
1) хранить в каталоге самой программы (e.g. — Настройки программы едины для всех пользователей этого компьютера)
2) хранить в каталоге пользователя — это уже пусть сами программисты решают что за каталог (e.g. — Настройки программы различаются для каждого пользователя).
Вообще сам являюсь поклонником /home, /etc всего что с ними связано) Мне кажется логичным строгое разграничение того, куда какие файлы программы складывать. Например при переустановке ОС — необязательно копировать все программы. Программы можно поставить и ручками. А вот возможность скопировать все настройки всех приложений (без поиска этих настроек по всем системным каталогам, размазанным тонким и редким слоем по жёсткому диску) — очень удобна.
На торренте :D:D
нужно сделать две папки my documents и program documents )
А в чем проблема хранить настройки в папке программы? Зачем засорять системные папки?
Ужос. На каком боку спать, на левом или на правом?
На самом деле обсуждается важный вопрос, зря вы так.
Скажу сразу, никакой озлобленности нет.)
Вопрос несерьезный, студенческий, зависит от множества факторов.
Вопрос несерьезный, студенческий, зависит от множества факторов.
Вопрос серьезный, потому что под windows хранение конфигурации происходит безсистемно. А потом страдают пользователи, которые не знают как бы не потерять свои файлы конфигурации.
Если, кто-то из «студентнов» зайдет сюда и почитает, есть вероятность что в следующий раз когда ему надо будет решать этот вопрос, он, зная все за и против, примет верное решение.И использует реестр для хранения настроек.
Если, кто-то из «студентнов» зайдет сюда и почитает, есть вероятность что в следующий раз когда ему надо будет решать этот вопрос, он, зная все за и против, примет верное решение.
то есть в электроникс артс игры пишут студенты?:(
Ну да, всё это описано в MSDN и есть API, возвращающие пути к местам хранения.
Для кроссплатформенных приложений есть стандарт: standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
Вкратце, конфии хранятся в ${XDG_CONFIG_HOME}/appname/ или, при отсутствии данной переменной, ${HOME}/.config/appname/
Странно, что никто не вспомнил.
Вкратце, конфии хранятся в ${XDG_CONFIG_HOME}/appname/ или, при отсутствии данной переменной, ${HOME}/.config/appname/
Странно, что никто не вспомнил.
замечательно, и кто этот стандарт поддерживает? Windows?
С каких это пор Мелкософт поддерживает стандарты или хотя бы участвует в их обсуждении?
От ОС требуется только установить переменную XDG_CONFIG_HOME, и то не обязательно. Из установленного у меня софта его поддеривают awesome WM, Chromium (opensource версия Google Chrome), и gtk. Большая часть (упомянутый выше The Gimp например) по старой привычке мусорит в ${HOME}/.appname.
В WinXP конфиги должны быть по-умолчанию в C:/Documents and Settings/username/.config/appname/. Или там, куда показывает пользовательский XDG_CONFIG_HOME.
В WinXP конфиги должны быть по-умолчанию в C:/Documents and Settings/username/.config/appname/. Или там, куда показывает пользовательский XDG_CONFIG_HOME.
Т.е. топик скорее звучит, как «Где, в Windows, программе хранить свои настройки?»…
А то ведь известно, что настройки хранятся в ~/Library/Preferences/[com/org].[publisher].[application].plist или без «~», когда уместо. (шутка, хотя особенно ревнивые могут поминусовать)
А так, вариант «User\Application Data» в случае, когда это персональное приложение и/или имеет настройки для каждого пользователя, и «All Users\Application Data», когда приложение должно иметь единый файл настроек для всех пользователей. Всё, как у взрослых приложений, а сейвы к играм, естественно, в «My Documents».
Думать тут, особенно, не над чем.
А то ведь известно, что настройки хранятся в ~/Library/Preferences/[com/org].[publisher].[application].plist или без «~», когда уместо. (шутка, хотя особенно ревнивые могут поминусовать)
А так, вариант «User\Application Data» в случае, когда это персональное приложение и/или имеет настройки для каждого пользователя, и «All Users\Application Data», когда приложение должно иметь единый файл настроек для всех пользователей. Всё, как у взрослых приложений, а сейвы к играм, естественно, в «My Documents».
Думать тут, особенно, не над чем.
Непонятная тема. Рассмотрен вопрос _где_ хранить настройки, но не рассмотрен вопрос _как_ хранить настройки. Например, сохраняем позиции окна в .ini-файл в директории с программой по такому образцу: создаю раздел с именем текущего пользователя и в этом разделе у меня ключи с позициями окна. В коде получаю имя пользователя с помощью GetUserName() и выдергиваю ключи из соответствующего раздела (а затем сохраняю).
По этому принципу мы противоречим утверждению «Плюс (вернее минус) настройки пользователей будут общими, никто не сможет настроить программу под себя или хранить в ней только персональные данные.» из первого пункта.
Мне кажется, есть смысл рассматривать подробнее _принцип_ хранения настроек, а не место. Потому что хранить оные можно где угодно [вплоть до удаленного сервера — если кто-то боится потерять настройки при крахе локальной системы :-)].
По этому принципу мы противоречим утверждению «Плюс (вернее минус) настройки пользователей будут общими, никто не сможет настроить программу под себя или хранить в ней только персональные данные.» из первого пункта.
Мне кажется, есть смысл рассматривать подробнее _принцип_ хранения настроек, а не место. Потому что хранить оные можно где угодно [вплоть до удаленного сервера — если кто-то боится потерять настройки при крахе локальной системы :-)].
и что мешает другому пользователю открыть этот файл и посмотреть/поправить настройки всех других?
Другому пользователю ничего не помешает и значения в реестре подкрутить в разделах HKEY_USER\*, и в директории AppData и Local Settings (если, конечно, на последние права не помешают). Если речь о _надежности_, то можно попользоваться такими штуками как Crypt(Un)ProtectData или LSA-хранилище. Контекст же предыдущего комментария был совсем иной.
если я не ошибаюсь, поправьте, HKEY_USER у каждого пользователя свой и есессно править чужой нельзя. ну а про файлы права должны мешать править файлы в личной директории другого пользователя. А по хранению всех настроек всех пользователей в одном файле, что мешает одному из них прибить этот файл? Как решается вопрос в случае, если одному из пользователей программа не нужна больше и он хочет удалить все свои настройки? Опять же перенос своих настроек на другой комп, бэкап, portable и пр.?
HKEY_CURRENT_USER у каждого свой (по сути это линк на HKEY_USERS\id-пользователя) — Вы правы. В HKEY_USERS (прошу прощения: в предыдущем комментарии 'S' пропустил) лежат все эти ветки и залезть в любую из них и отредактировать — можно. Отредактировать файлы в личных директориях других пользователей — тоже можно (кстати, большинство пользователей Windows работают под администраторами). Все те же права можно и назначить единому файлу настроек. И, если все работают под правами пользователей, а не под администраторами, то администратор может дать приложению возможность имперсонализировать себя под ним и править файл с той же структурой. Программа же, задав соответствующие права файлу, может запретить не только писать в него заданному пользователю, но и вообще читать. Можно поступить итого проще: создать файлы user1.ini, user2.ini… в поддиректории UsersSettings и раздать им права.
Резюмируя: Я продолжаю придерживаться мысли, что предложение хранить настройки в Windows где-либо в конкретном месте, либо в разных местах — непринципиально. Важен вопрос: _как_ их хранить и _как_ ими пользоваться.
По Вашим вопросам:
— Удалить настройки?: Программа удалит раздел с данными пользователя из файла.
— Перенести настройки?: Пользователь берет директорию с программой и копирует на другой компьютер вместе с настройками и не мучается с поиском файлов настроек в глубине %USERPROFILE%.
Резюмируя: Я продолжаю придерживаться мысли, что предложение хранить настройки в Windows где-либо в конкретном месте, либо в разных местах — непринципиально. Важен вопрос: _как_ их хранить и _как_ ими пользоваться.
По Вашим вопросам:
— Удалить настройки?: Программа удалит раздел с данными пользователя из файла.
— Перенести настройки?: Пользователь берет директорию с программой и копирует на другой компьютер вместе с настройками и не мучается с поиском файлов настроек в глубине %USERPROFILE%.
Можно поступить итого проще: создать файлы user1.ini, user2.ini… в поддиректории UsersSettings и раздать им права.Удаление пользователя с компа оставит его файл в Вашей директории = мусор. Не забываем что есть многопользовательские сервера, скажем на фирмах, с удаленным доступом, где пользователи достаточно часто удаляются/меняются. В случае с одним файлом настроек нужно будет решать проблемы одновременного доступа и пр. коллизии…
Программа же, задав соответствующие права файлу...
Если не ошибаюсь, программа должна работать под администратором для этого, нет?
— Удалить настройки?: Программа удалит раздел с данными пользователя из файла.
т.е. программисту нужно предусмотреть управление в программе, а пользователю запустить программу и найти этот пункт там? Не сложно ли?
— Перенести настройки?: Пользователь берет директорию с программой и копирует на другой компьютер вместе с настройками и не мучается с поиском файлов настроек в глубине %USERPROFILE%.
Вместе со всеми настройками всех пользователей? Зачем это ему?
Похоже, Вы пытаетесь перейти к плюсам и минусам предложенного мною способа. Об этом можно подискутировать, но предлагаю сделать это в личных сообщениях. Могу сказать точно: способ способу рознь. Например, для серьезных приложений, которые, к тому же, работают на многопользовательских серверах — мало смысла хранить настройки в .ini файлах такого плана. Польза многопользовательских настроек для портируемых приложений мне кажется сомнительной (хотя, возможно, и есть такие — спорить не буду). Подчеркну еще раз свою основную мысль: предложение хранить настройки в Windows где-либо в конкретном месте, либо в разных местах — непринципиально. Важен вопрос: _как_ их хранить и _как_ ими пользоваться.
Настройки лучше всего хранить в паке с самой программой. Портабельность и все такое.
Сразу видно, что вы пользователь Windows.
Настройки они на до и настройки, чтобы их изменять, а для этого нужны права. Классический пример настроечных файлов mysql:
/etc/my.cnf Общие параметры
DATADIR/my.cnf Параметры для сервера
defaults-extra-file Файл, указанный при помощи -defaults-extra-file=#
~/.my.cnf Параметры для пользователя
Заметьте, при определённых настройках, пользователи могут изменять настройки под себя и если кто-то затрёт свой my.cnf это не отразится на других пользователях.
Настройки они на до и настройки, чтобы их изменять, а для этого нужны права. Классический пример настроечных файлов mysql:
/etc/my.cnf Общие параметры
DATADIR/my.cnf Параметры для сервера
defaults-extra-file Файл, указанный при помощи -defaults-extra-file=#
~/.my.cnf Параметры для пользователя
Заметьте, при определённых настройках, пользователи могут изменять настройки под себя и если кто-то затрёт свой my.cnf это не отразится на других пользователях.
как? и какие именно проблемы Вы имеете в виду?
ну, для выуживания, как тут писали, есть спец. утилита в винде (я ей тоже не пользуюсь, может-таки стоит). Portable софт удобен, не спорю, но не весь софт можно сделать portable (да, «маленькие утилитки сисадмина», а допустим тот же 3Dmax, фотошоп и офис? Да они есть portable, но решается это, согласитесь, не самым красивым образом — виртуальной средой), не всё уместится на флешку и зачем тогда вообще компу винт, если все программы (да и документы, музыка, фильмы) на флешке?
А как насчет стандартного места хранения настроек приложения в unix-like OS?
Я имею в виду не только файлы, которые хранятся в домашней папке пользователя, но и глобальные конфиги приложения — где обычно хранятся, и где было бы удобнее.
Я имею в виду не только файлы, которые хранятся в домашней папке пользователя, но и глобальные конфиги приложения — где обычно хранятся, и где было бы удобнее.
Забавно, что для windows программистов это не очевидно.
почему-то у каждого вин-программиста своё личное мнение где ему хранить настройки программы.
например TotalCommander 7.03 все еще хранить свои настройки в файле wincmd.ini в папке windows.
Опять-же временные файлы почему-то не все программы пишут в папку указаную в переменной %TEMP% некоторые умудряются спрятать их подальше
например TotalCommander 7.03 все еще хранить свои настройки в файле wincmd.ini в папке windows.
Опять-же временные файлы почему-то не все программы пишут в папку указаную в переменной %TEMP% некоторые умудряются спрятать их подальше
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Где программе хранить свои настройки?