im Programmverzeichnis Datei ändern?

[zeras]

Hallo,

ich komme noch nicht klar mit den ganzen Restriktionen im Programmverzeichnis. Normalerweise werden ja die Anwendungsdaten in das Anwendungsverzeichnis geschrieben. Wie kann ich prüfen, ob ich doch Zugriff auf eine Datei im Programmordner habe? Mit FileGetAttr bekomme ich als Info, dass die Datei nicht schreibgeschützt ist. Ich habe aber trotzdem keinen Zugriff auf die Datei, da offensichtlich der Ordner ja schreibgeschützt ist. Müßte ich da den Ordner abfragen oder wie sollte ich vorgehen. Wenn ich mit FileGetAttr frage, kommt nur die Info, dass es sich um einen Ordner handelt.
Wie kann ich vorgehen?

[mkinzler]

Einfach davon ausgehen, dass es nicht geht und die Daten woanders ablegen!

[zeras]

Zitat:

Zitat von mkinzler (Beitrag 1159681)

Einfach davon ausgehen, dass es nicht geht und die Daten woanders ablegen!

Ja gut, das wäre die beste Lösung. Aber es könnte doch auch andere Pfade geben, die schreibgeschützt sind und man auf die gleichen Probleme stößt?

[mkinzler]

Nicht wenn man die von Betriebssystem dafür vorgesehene Verzeichnisse verwendet.

[Bummi]

Oder man wirft, wenn man es wie die Designer des Betriebssytems, eigener Software, namentlich MSSQL-Server ermöglichen möchte, die Regeln zu brechen, einen Blick auf CACLS.
(sorry für Ketzertum)

[Popov]

@zeras

Also im Programmeverzeichniss hast du als normaler Nutzer (kein Administrator) Leserechte, aber keine Schreibrechte. Hier geht es um Rechte, nicht Schreibschutz. Äpfel und Birnen.

Wenn du also prüfen willst ob du eine Datei ändern kannst, dann zuerst den Schreibschutz überprüfen und dann ob du Änderungsrechte hast. Klingt kompliziert, ist es auch. Du kannst dir irgendwo eine Funktion suchen die Prüft ob du Adminrechte hast, aber auch das muß nichts bedeuten. Auch einem Admin kann man die Schreibrechte nehmen.

Deshalb den einfachen Weg. Es gibt Ordner wo du deine Daten schreiben kannst.

Nur mal interessehalber: was willst du ändern?

[himitsu]

Zitat:

Zitat von zeras (Beitrag 1159679)

Hallo,

ich komme noch nicht klar mit den ganzen Restriktionen im Programmverzeichnis. Normalerweise werden ja die Anwendungsdaten in das Anwendungsverzeichnis geschrieben.

Normaler Weise? :shock:

Das ist schon seit Windows NT verboten.
Soviel zu Normal ... es ist also schon seit fast 13 Jahren verboten und wenn die Programmierer es immernoch nicht kapiert haben, dann sind sie selber Schuld.

Bis Windows XP hat es nur fast keiner gemerkt, weil nahezu alle nur mit Adminrechten unterwegs waren.
Was nicht sonderlich intelligent war, wie man an der Verbreitung von Schadsoftware gut erkennen kann.

Seit nun schon fast 6 Jahren hat Microfot dem endlich einen Riegel vorgeschoben und den automatisch erzeugten Standardbenutzer nicht mehr mit vollen Rechten ausgestattet.
Du hattest nun also schon 6 Jahre Zeit dich gezwungener Maßen daran zu gewöhnen.

Und auch schon vor WinNT gab es Standardverzeichnisse, für viele Daten, so daß man sich an diese Verzeichnisse noch viel länger dran gewöhnen konnte.

[mkinzler]

Zudem hat Microsoft zusammen mit der UAC auch die Verzeichnisvirtualisierung eingeführt, um nicht alle Programme der "Unverbesserlichen" nicht mit einem Schlag unbrauchbar zu machen.
Der Schuss ging imho nach hinten los, da es für die meisten immer noch keinen Grund gibt, ihre Vorgehensweise zu überdenken. Zudem ist das System nun unübersichtlich ( welche Version der Ini gilt nun?) Es wäre besser gewesen, die gelbe Karte zu zeigen.

[zeras]

Zitat:

Zitat von Popov (Beitrag 1159687)

Nur mal interessehalber: was willst du ändern?

Ist nicht ganz einfach zu erklären. Es gibt bestimmt tausende Lösungen.

Ich habe einige Programme, die auf verschiedene Art genutzt werden können.
1.) Einmal als normales Programm, wo der Admin das Prog installieren muss. Dann werden auch die Pfade eingehalten.

2.) Dann auf einem Server.
3.) Auf einem Terminalserver.

Es geht bei 2.) und 3.) eigentlich nur um die Anmeldedaten. Diese sollen nicht von jedem User eingegeben werden müssen, sondern sollen schon freigeschaltet werden können. So habe ich diese erst mal in den Programmordner mit kopiert beim Setup. Danach muss aber der Kunde noch einmalig die Freischaltedaten eintragen. Wenn er das nicht im Programmpfad machen kann, weil keine Rechte, dann müßte das Programm dann im Userpfad die Anmeldedaten mit ablegen. Wenn er aber Rechte hat, dann wärden die Anmeldedaten dann für alle User gültig.
So das mal im Groben erklärt.
Ich werde mal überlegen, wie ich das noch anders lösen kann.

[Bummi]

Mit den entsprechenden Rechten in HKEY_LOCAL_MACHINE

[Popov]

@zeras

Ein ähnliches Problem habe ich auch gerade (aber wirklich nur ähnlich), und muß zugeben für mich noch keine zufriedenstellende Lösung gefunden zu haben. Denn ich stehe vor dem Problem Daten zu einem Programm mitzuliefern, ohne die das Programm eigentlich nutzlos ist (somit muß es jedem Konto zur Verfügung stehen), auf der anderen Seite sollen die Nutzer die Daten individuell anpassen können. Und mit diesen Anforderungen stehe ich eigentlich vor einem Ding der Unmöglichkeit. Denn Windows bietet die Möglichkeit nicht, zumindest nicht ohne weiteres. Denn Programme Verzeichnis bietet keine Schreibrechte, Anwendungsdatenordner ist nur für den Nutzer zugänglich, und gemeinsame Dateien hört sich zwar vielversprächend an, ist aber nur ein Ordner den jeder sehen kann, aber nicht in dem jeder Schreibrechte hat.

Um auf den Punkt zu kommen: ich hab mir paar Wochen den Kopf zermartert, aber es gibt hier keine Lösung.

Das einzige was man machen kann ist eine Pseudolösung, die die Nutzer akzeptieren müssen.

[zeras]

Zitat:

Zitat von Popov (Beitrag 1159719)

Um auf den Punkt zu kommen: ich hab mir paar Wochen den Kopf zermartert, aber es gibt hier keine Lösung.

Da bin ich dann wohl doch nicht der Einzigste.
Im Moment frage ich im Programmverzeichnis die Daten ab, die bei der Installation mitkommen und dann noch im Userpfad. Geschrieben wird aber alles dann in den Userpfad. Mit der Registry wollte ich nicht anfangen, da ich kein Freund davon bin. Je mehr Programme dort reinschreiben, umso langsamer wird das System. OK, nun habe ich eine SSD und Win7 und das ist meines Erachtens sehr schnell, aber was ist in einem Jahr? Dann habe ich noch weitere Programme installiert und das System läuft dann wieder langsamer. Aber das ist Philosophisache.

[bernerbaer]

Zitat:

Zitat von zeras (Beitrag 1159721)

Da bin ich dann wohl doch nicht der Einzigste.

Einzigste

Zitat:

Zitat von zeras (Beitrag 1159721)

Mit der Registry wollte ich nicht anfangen, da ich kein Freund davon bin. Je mehr Programme dort reinschreiben, umso langsamer wird das System. ...

sagt wer? Die Registry ist meines Wissens eine Datenbank, die Auswirkungen auf die Geschwindigkeit des Systems durch eine sehr grosse Registrierungsdatenbank sollten sich deshalb meines Erachtens höchstens im Bereich von Millisekunden bewegen.

[cookie22]

Zitat:

Mit der Registry wollte ich nicht anfangen, da ich kein Freund davon bin. Je mehr Programme dort reinschreiben, umso langsamer wird das System.

Mit Win95 und einem 486er mag das noch zutreffend gewesen sein, heute sicher nicht mehr.:wink:

[himitsu]

Im Notfall kann man sogar eigene Registryzweige erstellen, welche in einer externen Datei liegen.
Und da die Registry nie komplett geladen ist, sondern sich nur grade verwendete Teile in einer Cache liegen.
Das Dateisystem wird ja auch nicht urplötzlich langsamer, nur weil in irgendeinem Unterverzeichnis zuviele Dateien befinden.

Die Registry ist eine wichtige Datenablage, da kann man schon davon ausgehn, daß Microsoft dort ein bissl Arbeit in die Optimierung steckt.

RegLoadKey

Die Registry besteht sowieso schon aus mehreren Teilen und einige Teile existieren noch nichtmal in Echt.
HKEY_CLASSES_ROOT existiert garnicht. Das ist ein zusammengemischter Unterpfad aus HKEY_CURRENT_USER und HKEY_LOCAL_MACHINE.
HKEY_CURRENT_CONFIG und HKEY_CURRENT_USER sind auch nur benutzerabhängige Unterpfade aus HKEY_USERS.
...

[Sir Rufo]

@Popov

Ich weiß zwar nicht um welche Daten es sich handelt, aber ich habe so was teilweise mit Ini-Dateien.

Die Lösung sieht da aber recht einfach aus. Die Ini-Datei aus dem Programm-Verzeichnis Und dem User-Verzeichnis werden jeweils eingelesen TMemIniFile. Über eine separate Klasse, die die Einstellungen kapselt, werden die Einstellungen gelesen.

Existiert ein Eintrag in der User-Ini, wird dieser genommen, ansosnten der aus der Programm-Ini.

Änderungen werden logischweise nur in die User-Ini geschrieben.

Analog lässt sich dieses auch mit jedem beliebigen Datei-Format bewerkstelligen.

[Popov]

@Sir Rufo

Das eigentliche Produkt sind die Dateien, das Programm dient lediglich um die Dateien zu nutzen. Es ist zwar ein wichtiger Bestandteil, denn ohne, sind die Daten nutzlos, aber trotzdem, auf die Daten kommt es an. Wenn ich Excel installiere, dann ist Excel das Produkt, wenn ich Nero installiere, dann ist eben Nero das Produkt. Jeder kann sie von jedem Konto aus nutzen. Hier sind die Daten das Produkt. Aber Daten sind nun mal Daten und können im Gegensatz zum Programm geändert werden. Und das ist das Besondere.

Das Programm das ich klone macht das einfach: die Daten liegen im Programmeordner und können somit nur im Adminkonto geändert werden. Ich hab einigen Nutzer des anderen Programms gesprochen und die meinen, das ist nun mal so, damit muß man leben. Es wird also akzeptiert. Trotzdem, jedes mal für eine Anpassung das Konto wechseln ist nicht optimal.

Ich biete inzwischen eine Pseudolösung an, weil es nicht anders geht. Der Nutzer kann sich eine Kopie der Datei erstellen und kann diese ändern. Er hat eben die Wahl: ins Adminkonto wechseln und es für alle Konten ändern, oder im Konto kopieren und es nicht nicht in anderen Konten nutzen können. Eine andere Lösung gibt es nicht.

[Furtbichler]

Es ist schade, das Windows es (noch nicht) fertig bringt, den Kontext "Applikation" als Tupel von (Code, statische Daten, gemeinsame Daten aller Nutzer, dynamische Daten pro Benutzer) zu sehen, sodaß der einfache Anwender es versteht.

Klar gibt es eine sehr sinnvolle Regel, aber ich muss im Explorer trotzdem wissen, wo ich suchen muss.

Was passiert eigentlich, wenn ich bei der Installation (als Admin) im Programmordner einen Link zu <AppData>\<MeinProgramm> anlege? Wäre das nichts?

[Popov]

Es gibt neben Gemeinsame Dokumente auch All Users Anwendungsdaten, also Anwendungsdaten Ordner für alle. Allerdings haben da nicht alle dort Schreibrechte. Somit es es das gleiche wie Daten in Programme-Ordner, nur in grün.

[Iwo Asnet]

Die anwenderspezifischen Einstellungen kommen in den anwenderspezifischen Ordner.
Die allgemeingültigen Einstellungen eben in den allgemeinen Ordner. Wer darauf keine Schreibrechte hat, darf anderen Anwendern wohl auch nicht vorschreiben, was bzw. wie sie etwas zu tun haben.

Desweiteren gibt es -sofern ich mich erinnere- 'öffentliche Dokumente'.

Erstelle die Unterverzeichnisse so, wie Furtbichler beschrieben hat, also als Link auf die zugegebenermaßen etwas versteckten, aber richtigen Verzeichnisse. Dann sind die Daten und Programme alle gemeinsam sichtbar.

Nebenbei: Egal, was Du vorhast: Ich werde mein Windows immer so kaputtkonfigurieren können, das irgend etwas nicht geht.

Es reicht, wenn es in 99% der Fälle funktioniert, weil 99% der Anwender die Finger vom Rechtesystem lassen.

Merke: Man muss nicht jeden Fall erschlagen, sondern nur dokumentieren, in welchen Fällen die Applikation funktioniert.

Ein Auto fährt ja auch nicht mit Wasser, nur weil es im Amazonas keine Tankstellen gibt, aber einem dort vielleicht das Benzin aus geht.

[Popov]

Iwo Asnet, die Sichtbarkeit ist kein Problem.

[Furtbichler]

Es ging doch ursprünglich darum, das Daten und Programm "so weit auseinander" liegen, wenn man die Windows-Vorgaben benutzt, also die 'Anwendungsdaten' Verzeichnisse verwenden. Die Idee von Iwo Asnet ist doch gut. Dann hat man gleich alles im Blick (Programme und Daten)

Dann bietet man in der eigenen Anwendung an, die Einstellungen 'für alle Benutzer' oder 'nur für sich selbst' zu speichern. Was nicht gehtm, ist eben ausgegraut, wenn man keine Zugriffsrechte hat. Wo ist denn da nun das Problem?

Nicht Windows soll sich anpassen, sondern die Programmierer.

[Sir Rufo]

Trotz allem ist der Ordner AppData hier der richtige (auch wenn default nicht alle User dort Schreibrechte haben), denn bei der Installation kann man dafür sorgen, dass eben alle (genau) darauf Schreibrechte bekommen (oder halt nur auf bestimmte Dateien darin).

Also in CSIDL_COMMON_APPDATA\<Company>\<Product>\ die Anwendungsdaten für alle und die Berechtigungen anpassen.

Und für die Benutzer-spezifischen Anwendungsdaten CSIDL_APPDATA\<Company>\<Product>\

[p80286]

Zitat:

Zitat von Sir Rufo (Beitrag 1159909)

Trotz allem ist der Ordner AppData hier der richtige (auch wenn default nicht alle User dort Schreibrechte haben), denn bei der Installation kann man dafür sorgen, dass eben alle (genau) darauf Schreibrechte bekommen (oder halt nur auf bestimmte Dateien darin).

Also in CSIDL_COMMON_APPDATA\<Company>\<Product>\ die Anwendungsdaten für alle und die Berechtigungen anpassen.

Und für die Benutzer-spezifischen Anwendungsdaten CSIDL_APPDATA\<Company>\<Product>\

Dem ist doch nichts mehr hinzu zu fügen.

Gruß
K-H

[Popov]

Zitat:

Zitat von Furtbichler (Beitrag 1159906)

Es ging doch ursprünglich darum, das Daten und Programm "so weit auseinander" liegen...

Wie gesagt, zumindest bei mir (evtl. anders als der Threadersteller) lag das Problem nicht darin einen Ordner zu finden auf den alle Leserechte haben. Da gibt es sogar mehrere Möglichkeiten und man kann aus dem Vollen schöpfen. Schreibrechte sind das Problem, denn es gibt keinen Ordner der von sich aus das bietet, wenn auch technisch möglich.

Zu AppData Ordner, ob privat oder öffentlich. Das Problem ist nicht MS, oder doch zum kleinen Teil, denn es fehlt eigentlich noch ein Ordner. In Dokumente speichere ich Dokumente, in AppData Einstellungen, wie sieht es aber z. B. mit den Bookmarks von Firefox oder der Postdatei von Outlook aus? Eigentlich kein Dokumente, aber doch mehr als eine Ini die die letzte Fenster-Position speichert. Und wo ist diese wichtige Datei gespeichert? In einem Ordner den der 08/15 Anwender nie im Leben finden wird, weil versteckt. Wenn man nicht zufällig ein Komplett-Backup macht, dann wird man bestimmt kein Backup von einem unsichtbaren Ordner machen. Hier fehlt also ein Zwischending.

@Furtbichler

Ich denke wir meinen das gleiche, reden aber aneinander vorbei.

@Sir Rufo

Zitat:

Also in CSIDL_COMMON_APPDATA\<Company>\<Product>\ die Anwendungsdaten für alle und die Berechtigungen anpassen.

So schlau war ich eigentlich auch, aber die Berechtigungen für alle anpassen ist nun das kleine Problem. Wenn ich vor dem Rechner sitze ist das kein Klaks, bei der Installation wohl ein minder großes Problem.

[DeddyH]

Zitat:

Zitat von Popov (Beitrag 1159943)

Wenn ich vor dem Rechner sitze ist das kein Klaks, bei der Installation wohl ein minder großes Problem.

Z.B. InnoSetup kennt da einen Parameter dafür IIRC.

[p80286]

Zitat:

Zitat von Popov (Beitrag 1159943)

So schlau war ich eigentlich auch, aber die Berechtigungen für alle anpassen ist nun das kleine Problem. Wenn ich vor dem Rechner sitze ist das kein Klaks, bei der Installation wohl ein minder großes Problem.

Und was spricht dagegen eine Gruppe zu nutzen?
Die wird einmal eingerichtet (Rechte) und nach Bedarf werden die Nutzer dazu oder weg genommen.
(das Problem hier sind doch nur die Entscheider die nicht entscheiden können wer was dürfen soll)

Gruß
K-H

[Popov]

Zitat:

Zitat von p80286 (Beitrag 1159957)

Und was spricht dagegen eine Gruppe zu nutzen?
Die wird einmal eingerichtet (Rechte) und nach Bedarf werden die Nutzer dazu oder weg genommen.

Wir sind hier in einem Programmiererforum und nicht in einem Windows-Admin Forum. Ich kann, wenn ich vor dem Computer sitzen für alle eine Gruppe mit bestimmten Rechten erstellen, das ist kein Problem. Hier geht es aber drum ein Programm zu verschenken oder zu verkaufen, d. h. der Nutzer läd sich das Programm aus dem Internet und installiert es im Programmeverzeichnis.

Sicher, ich kann in meinem Programm eine Funktion einbauen die mir eine Gruppe mit Sonderrechten erstellt, vielleicht macht das auch ein Setupprogramm, dann binde ich es in alle bestehenden Konten ein, aber auch für alle zukünftig erstellten Konten, usw. usw. usw.

Ich verstehe nicht auf was du eigentlich hinaus willst? Du lieferst für ein Problem zwar logische, aber dennoch billige Lösungen. Das ist wie: wenn sich Israelis und Iraner wieder lieb zu haben, dann wird es keinen Krieg geben. Das ist zwar logisch, daran ist nichts verkehrt, theoretisch würde es sogar funktionieren. Auch deine Lösung ist theoreisch möglich. Ich habe ein kleines Tool und damit es funktioniert greife ich tief in das System, erstelle Gruppen mit Sonderrechten, weise die den Konten zu, usw.