Невозможно изменить файл .ini в каталоге c: \ windows

Question

Я пишу приложение на C # для Windows, чтобы обновить файл .ini для устаревшего приложения.У меня нет исходного кода унаследованного приложения, поэтому я не могу его изменить.

Устаревшее приложение сохраняет настройки в INI-файле в C: \ Windows.Это местоположение не может быть изменено.

Чтобы изменить настройки INI, я использовал следующие функции Windows:

[DllImport("kernel32.dll", EntryPoint = "GetPrivateProfileString")]
private static extern int GetPrivateProfileString(string lpAppName, string lpKeyName, string lpDefault, StringBuilder lpReturnedString, int nSize, string lpFileName);

[DllImport("kernel32.dll", EntryPoint = "WritePrivateProfileString")]
private static extern bool WritePrivateProfileString(string lpAppName, string lpKeyName, string lpString, string lpFileName);

Кажется, вышеупомянутые функции не изменяют файл INI, однако последующие вызовы «GetPrivateProfileString» показываютправильные / измененные значения.

Кроме того, я даже пытался записывать напрямую в INI-файл, используя классы System.IO.Похоже, это не изменило INI-файл.

Если я попытаюсь скопировать файл в каталог приложения, а затем записать настройки INI, будут записаны правильные значения.Если затем я попытаюсь скопировать этот измененный файл обратно в C: \ Windows, исходный файл INI, похоже, не будет изменен.

Похоже, что на уровне ОС происходит какой-то тип кеша файлов INI?

Если я вручную редактирую файл INI с помощью текстового редактора, файл INI обновляется.

Как предлагалось на других форумах, я также пробовал этот код после написания настройки INI:

WritePrivateProfileString(null, null, null, filename);

Моя проблема в том, что унаследованное приложение не принимает изменения файла INI (даже после перезапуска унаследованного приложения).

Answer 1

В рамках UAC приложения без манифеста UAC, которые пытаются выполнять действия, запрещенные UAC, подлежат виртуализации. Это записывает в зеркальное местоположение вместо защищенного местоположения. Когда вы пытаетесь прочитать, если в расположении зеркала есть файл, вы получаете этот файл. Таким образом, ваше приложение будет работать, даже если оно написано вопреки лучшим практикам того времени.

Чтобы найти расположение зеркала, откройте проводник Windows в папке и найдите кнопку на панели инструментов с надписью «Файлы совместимости»:

Возможно, этого вам достаточно - теперь, когда вы знаете, где искать, вы можете доверять виртуализации, и приложение будет работать правильно. Если нет, попробуйте добавить в приложение внешний манифест. Манифест «1006» предотвратит виртуализацию, и запись не удастся. Если в приложении есть обработка ошибок (например, возврат в другое место), возможно, это хорошо. Манифест «1007» предотвратит виртуализацию, и запись будет выполнена успешно. Однако согласие UAC, вероятно, будет раздражать ваших пользователей.

(Кстати, это изображение из моей записи в блоге, в которой немного больше говорится о виртуализации. http://www.gregcons.com/KateBlog/FindingFilesYoureSureYouWrote.aspx)

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

Answer 2

Это началось с Vista, чтобы повысить безопасность.Если приложение пытается выполнить запись в защищенное местоположение (например, ini-файлы, записанные в папку приложения в ProgramFiles или в папку Windows, операции чтения и записи в этом файле перенаправляются в папку в C: \ Users {имя пользователя)} \ AppData \ Local \ VirtualStore \

Answer 3

значения записываются, но в какой-то «зеркальный» файл, который находится где-то еще - это часть волшебства, которое выполняется под капотом, чтобы не сломать устаревшие приложения и при этом сделать более безопасную ОС ... см. http://technet.microsoft.com/en-us/library/dd837644%28WS.10%29.aspx