Błąd odmowa dostępu przy zapisywaniu pliku w C:\Program Files(x86)

Jak naprawić błąd odmowy dostępu przy zapisywaniu pliku w C:\Program Files(x86) chodzi o plik language.ini
Zrobiłem instalator z aplikacją, zainstalowałem apkę do C:\Program Files(x86) i przy wyjściu z apki mam kod który zapisuje język programu do pliku "language.ini"

procedure TForm1.FormCloseQuery(Sender: TObject; var CanClose: Boolean);
var
  r: Integer;
begin
  //zapytanie
   if StringGrid.Modified then
     begin
       r:=MessageDlg(OnCloseCaptionMes + #13 + ifSaveText, mtWarning,     [mbYes,mbNo,mbCancel],0);
       case r of
       mrYes:
       begin
         if OD.FileName <> '' then
         begin
            MenuItem4Click(Sender);
            CanClose := True; 
         end
          else
          begin
            if SD.Execute then
            begin
            MenuItem4Click(Sender);
            CanClose := True; 
            end
          else
            //Action := caNone;
            CanClose := False; 
          end;
       end;
       mrNo:
         CanClose := True; 
       mrCancel:
        CanClose := False; 
       end;
     end
   else
    CanClose := True; 
end;           

A uruchomienie z prawami admina?

Jak w systemie jest ustawione, że dysk C cały wywmaga admina, a tylko katalog użytkownika nic nie wymaga to musisz podwyższyć uprawnienia.
ALe jak chcesz wirusów uniknąć to musisz dać możliwość instalowania się bez uprawnień admina, ale ograniczać dostęp do wszystkiego.
W telefonach każda aplikacja to inny użytkownick i nikt drugiego nie może odczytać, ale mogą korzystać ze wspólnej pamięci, która nie jest bezpieczna.

Jak uruchamiam z prawami admina to nie ma błędu. Robię instalator w inno setup

Zainstaluj aplikację w %appdata% danego użytkownika, jeśli dysk C jest pod prawami administratora, zawsze masz user files/użytkownika nazwa i tu możesz już normalnie zapisywać bez admina

Musisz za bardzo polegać na Dysku C, gdzie tam zwykle ograniczna się dostęp żeby wirusy się łatwo nie rozprzestrzeniały.

Tak szczerze microsoft powinien wyświetlać komunikat, żadna aplikacja nigdy nie powinna prosić cię o prawa Admina, i jeśli ta aplikacja nie powinna mieć takich uprawnień nie poiwinieneś się zgadzać, bo inaczej prędzej czy później ktoś podsłucha cię i ukradnie ci hasła

Po pierwsze zacznijmy od tego, że oprogramowanie powinno być zainstalowane tam, gdzie życzy sobie tego użytkownik — żadnego hardkodowania ścieżki, tym bardziej w katalogu z lokalnymi plikami użytkownika (jak to robi(ł) gówniany Chrome). Do tego powinien służyć instalator, który wymusza uruchomienie z uprawnieniami administratora — dzięki temu może wypakować pliki programu gdziekolwiek oraz uzupełnić rejestr w wymagane dane.

Program podczas startu powinien sprawdzać czy instalacja jest poprawna, czyli najpierw odczytywać swoją lokalizację z rejestru systemu (te dane dodaje do rejestru instalator), a następnie sprawdzać i ładować wymagane do działania pliki. Wszystkie pliki służące wyłącznie do odczytu, bez których program nie może poprawnie działać, powinny się znajdować w katalogu instalacji. Sam program, jeśli do swojego typowego działania nie wymaga uprawnień administratora, to nie powinien w ogóle ich żądać od użytkownika.

Jeśli program potrzebuje dynamicznie tworzyć pliki, np. z ustawieniami i innego rodzaju konfiguracjami, powinien te pliki tworzyć wewnątrz systemowego katalogu przeznaczonego do tego celu. Tutaj ważne jest to, że każdy program może swobodnie w tych katalogach zapisywać dane, nawet działając z najniższymi uprawnieniami. Przy czym możliwe jest zapisywanie danych tylko dla bieżącego użytkownika lub w taki sposób, aby były dostępne dla wszystkich użytkowników.

W przypadku, gdy program działa z podstawowymi uprawnieniami, ale niektóre jego funkcje wymagają uprawnień administratora, należy o nie poprosić użytkownika, tylko na potrzeby przeprowadzenia konkretnej operacji. Z tego co mi wiadomo, uprawnień działającego procesu nie da się dynamicznie zmienić, dlatego też rozwiązaniem jest uruchomienie innego pliku wykonywalnego (lub drugiej instancji tego samego programu), aby wykonała tę operację i natychmiast zakończyła działanie, zwracając rezultat do głównej instancji. To robi się za pomocą polecenia runas, które w przypadku włączonego UAC, wyświetla systemowy dialog z prośbą o nadanie uprawnień administratora żądającej ich aplikacji.

Podsumowując, zadaniem instalatora jest wymuszenie uprawnień admina przy starcie, wypakowanie plików programu do wybranej przez użytkownika lokalizacji, uzupełnienie rejestru systemu w dane umożliwiające lokalizację instalacji oraz jej deinstalację (i wszelkich innych danych w chronionych gałęziach rejestru), a także jeśli potrzeba, stworzenie dedykowanego katalogu w systemowym folderze lokalnych danych użytkownika.

Zadaniem deinstalatora jest również wymuszenie uprawnień administratora, sprawdzenie poprawności instalacji, pobranie z rejestru ścieżki instalacji, usunięcie wszystkich plików programu oraz opcjonalnie danych zgromadzonych w katalogu z lokalnymi danymi, usuniecie danych z rejestru oraz samego siebie.

Sam program nie powinien wymagać uprawnień administratora, chyba że są one konieczne. Jeśli potrzebuje gdzieś zapisywać dane, to powinien to robić w przeznaczonych do tego celu katalogach. Jeśli użytkownik zechce zapisać dane w chronionym katalogu (np. w C:\Windows\), to program tylko do tej operacji powinien pytać o podniesienie uprawnień — w przeciwnym razie powinien być napisany tak, aby reagował na odmowę dostępu (czyli miał dodaną pełną obsługę błędów). Jeśli program musi modyfikować dane rejestru systemu, to również musi dynamicznie prosić o uprawnienia admina, o ile modyfikacja dotyczy chronionych gałęzi (jak np. HKEY_LOCAL_MACHINE).

Gdybyś potrzebował przykładu, to mogę taki podrzucić — w swoich edytorach implementowałem dynamiczne żebranie o uprawnienia admina, na potrzeby rejestracji ich lokalizacji na dysku oraz obsługiwanych przez nie rozszerzeń plików. Te dane trzeba dodać do chronionych gałęzi rejestru, takich jak HKEY_LOCAL_MACHINE oraz HKEY_CLASSES_ROOT, a to wymaga najwyższych uprawnień.

I bardzo k... dobrze, C:\Program Files(x86) ma być read-only. Jak chcesz coś zapisać to albo w katalogu użytkownika tzw. AppData (C:\Users\$USER\AppData) albo w danych programu C:\ProgramData.

Polecam trzymać pliki modyfikowalne per user.

Zgadzam się z @0xmarcin jeżeli jednak już planujesz na etapie pisania zapisywanie do ścieżki która by default nie jest do zapisu/modyfikacji to musisz w instalatorze nadać uprawnienia do zapisu

Zrobiłem przykład zapisu języka aplikacji do C:\Users\$USER\AppData\test\language.ini
Zapis do AppData langugae.zip

@Programista Art Użyj TPath.GetHomePath z modułu System.IOUtils chyba, że FP ma coś lepszego.

FP ma np. funkcję GetAppConfigDir, która zwraca ścieżkę systemowego katalogu przeznaczonego do zapisu ustawień. Jest też funkcja GetUserDir, zwracająca ścieżkę katalogu użytkownika. Tego typu funkcje są wieloplatformowe, stąd zalecane ich używanie.

Dla platformy Windows jest np. funkcja GetWindowsSpecialDir z modułu WinDirs.