2 BUGS in TC!!! Juchhei

[brainstuff]

Ich habe jetzt 2 Bugs in TC gefunden ... Juchei ... endlich ... ich hatte schon die Hoffnung aufgegeben! Bekomme ich jetzt 5 Disketten????

BUG 1: in Windows 7 kommt TC nicht mit SUBST-Drives zurecht! Ich habe mit xsubst einen drive B geschaffen. Der wird im Explorer angezeigt, aber TC will den nicht kennen!!! Da ich mir dachte, der Drive B ist etwas sehr exotisch (B war früher einmal ein anderer Name für den Drive A:). Habe ich es auch mit Z: versucht .. auch das geht nicht in Windows 7 (in Windows 8 geht es!!).

Hier hat es 2 screen shots ... http://mail2vip.com/vippages/tc_drives/
Der drive A: ist ein RAM Disk .. z: ist ein "Container" auf der Explorer Liste hat es den xsubst drive B: der in TC fehlt

OK ... vielleicht ist das irgend ein Problem von meinem System und nicht von TC! Der Drive wird aber auch nach einem Neustart in TC nicht angezeigt.

BUG 2: ist ein etwas exotisches Problem, aber es ist ein wirkliches Problem. Ich habe ein System, wo die TC ini Files auf ein spezielles Laufwerk ausgelagert sind. Wenn dieses Laufwerk nicht am Computer hängt, dann findet TC seine ini Files nicht, die sind nämlich auf dem nicht dranhängenden Laufwerk! Soweit ist das "normal" ... dann startet TC ganz normal, aber mit der original Konfiguration. Auch das ist noch normal. Nur: es ist dann nicht möglich, die TC Konfiguration zu ändern ... zum Beispiel kann man nicht einstellen, dass die hidden Files angezeigt werden. Da steht man dann plötzlich vor einem Laufwerk C: wo die Hälfte fehlt, weil vieles hidden ist. Und man kann an TC nichts ändern! TC will immer seine INI Files auf das nicht vorhandenen Laufwerk schreiben.

Ich bin mir bewusst, dass das ein sehr exotischer Bug ist ... aber es braucht trotzdem eine Routine, die bei fehlendem Laufwerk für die Ini-Files, fragt "Ini-Dateien im TC Ordner abspeichern"?

OK ... jetzt kommt bestimmt jemand und sagt: das ist kein BUG, sondern ein mega geiles Feature! Damit kann man die "Lölli's", die die Finger von den hidden Files lassen sollen, abschrecken!

OK .. dann habe ich keinen BUG gefunden, sondern ein "Feature" und bekomme dafür 6 Disketten in meinem Profil????

Ich wünsche euch ein erfolgreiches neues Jahr.

brainstuff

[sqa_wizard]

Ich habe mit xsubst einen drive B geschaffen

Ja, das ist eine bekannte und so gewollte Einschränkung (reserviert für Diskettenlaufwerk)

Habe ich es auch mit Z: versucht .. auch das geht nicht in Windows 7 (in Windows 8 geht es!!).

Drive Z: ist bei dir bereits von einem lokalen Laufwerk belegt.


Ich habe erfolgreich unter Windows 7 mit

Code: Select all

subst z: e:\tmp

ein Laufwerk Z: erstellt und kann es im TC auch sehen.

[Dalai]

Ich bin mir bewusst, dass das ein sehr exotischer Bug ist ... aber es braucht trotzdem eine Routine, die bei fehlendem Laufwerk für die Ini-Files, fragt "Ini-Dateien im TC Ordner abspeichern"?

Damit es dann zwei Sätze von Konfigurationsdateien gibt und der Anwender mit Sicherheit den falschen bearbeitet? Dazu kommt noch, dass Benutzer in aller Regel gar nicht in dieses Verzeichnis schreiben können, jedenfalls nicht, wenn TC unterhalb von %ProgramFiles% bzw. %ProgramFiles(x86)% installiert ist. Außerdem ist das Standardverzeichnis für die Konfiguration ab Vista %AppData%\Ghisler.

Zu dem ersten Problem kann ich momentan nichts sagen, denn die verlinkte Webseite ist momentan dicht, braucht zu lange zu reagieren.

MfG Dalai

[Dalai]

Ich habe mit xsubst einen drive B geschaffen

Ja, das ist eine bekannte und so gewollte Einschränkung (reserviert für Diskettenlaufwerk)

Nö. Ich hab hier kein Problem, mit

Code: Select all

subst b: c:\

auf einer CMD eine vorhandene Festplatte zu einem Laufwerk B: zu machen, egal ob unter XP oder Win7 (x64) und egal ob Admin oder nicht.

Kann es sein, dass xsubst Probleme mit Win7 hat? Oder wird TC als anderer Benutzer ausgeführt als der Explorer? Gesubstete Laufwerke sind wie Netzlaufwerke nutzerspezifisch!

MfG Dalai

[MC]

Ich seh's schon kommen - wird wieder nichts mit den 5 Disketten... LOL

[Kerstin83]

Was denn für 5 Disketten? Wurde das mal als Preis ausgeschrieben?
Disketten sind ja enorm im Wert gestiegen, muss man im Laden richtig was für bezahlen

[Dalai]

[OT]

2Kerstin83
Es geht wohl um die Disketten im Nutzerprofil, unter dem Status "Junior/Senior/Power Member", die, soweit ich weiß, nur von der Anzahl der Beiträge (ggf. pro Zeiteinheit) abhängen - und da gibt's auch nur maximal 4.

[/OT]

MfG Dalai

[brainstuff]

@dalai und @(kiss)

Danke für Eure Mühewaltung ...

Nachdem mir Kiss gesagt hat, dass es bei ihm mit dem alten subst geht habe ich ein wenig herumprobiert ... und ich komme aus dem Staunen nicht mehr raus ...

Hier hat es ein Mosaik von screen shots: http://mail2vip.com/vippages/tc_drives/drives%203.jpg links oben sind die drives von TC ...darunter der screen von xsubst, daneben die Drives im Explorer und ganz rechts diese Liste:

A: Ram Disk
B: subst disk mit xsubst
C: HDD
D: subst disk mit xsubst
E: subst disk mit subst
F: subst disk mit xsubst
G: subst disk mit subst
H: frei
I: frei
J: subst disk (woher das kommt weiss ich nicht)
K: frei
L: frei
M: externes Disk von einem NAS (nicht angeschlossen)
N: externes Disk von einem NAS (nicht angeschlossen)
O: frei
P: NAS 01-1
Q: NAS 01-2
R: NAS 01-3
S: NAS-02-1
T: frei
U: frei
V: NAS-02
W: cloud Laufwerk
X: *** bitte in meinem Kommentar anschauen""
y: true crypt container
z: true crypt container

TC kennt das A: .. das B: kennt er nicht (vielleicht ist das die alte Geschichte mit den Drives A und B die eine Floppy waren, da das aber ein mit xsubst erzeugter drive ist .... kommt das vielleicht daher) Der Explorer kennt den Drive B .. .

Die mit dem original subst erzeugten drives kennt nur TC ...Die mit xsubst erzeugten Drives kennt nur der Explorer.

Ich habe aber etwas gefunden ... was mir "Kiss" vielleicht bestätigt .... ich nehme an, er hat subst in der Kommando-Linie von TC gestartet .. wie ich das auch normalerweise mache. Deshalb habe ich mal geschaut was passiert, wenn ich subst in der Komandozeile von Windows starte .. und da
erscheint der subst-drive dann im Explorer aber nicht im TC! Und da xsubst ein Program ist, was ausserhalb von TC startet ... könnte das die Erklärung sein ... TC übernimmt das nicht richtig ....

Und wegen dem Laufwerk X: ... da brauche ich bald einen Psychiater!!!!!! Mit diesem Mist-Laufwerk ärgere ich mich jetzt schon seit Monaten herum! Und jetzt sehe ich etwas, was aussieht wie ein Scherz:

In TC ... steht bei dem Laufwerksbuchstaben, wenn man mit der Maus drüber fährt "Mirroir of c:" und wenn man sich die Dateienliste in tc anschaut ist das auch der Drive C: ... nur ich finde absolut nicht heraus, wo dieser Mirroir herkommt (ich brauche den drive C: nicht 2 x, ich habe schon Angst, dass mir die Lw. Buchstaben ausgehen). In der Liste vom x-subst ist das dann aber plötzlich der subst Dir c:\_DATA (das ist der aber offensichtlich gar nicht. .. weil ja der Root Directory vom C: in TC angezeigt wird)... aber, wenn ich dann im Explorer auf den Drive X gehe ... bin ich in c:\_DATEN!

Ich habe bei diesem X: Drive noch etwas versucht ... in xsubst habe ich dieses Laufwerk "getrennt" .. dann passiert auch etwas ungewöhnliches ... der Drive X: ist nicht mehr c:\_DATEN sondern wandelt sich in "mirroir of c:" um und ist nicht mehr trennbar...

Wenn TC die auf Windows-Ebene erzeugten subst drives wirklich nicht erkennt, dann ist das ein BUG in TC und ich werde 6 EHREN Disketten in meinem Profil bekommen ... OK eigentlich gibt es nur maxiamal 5 ... aber wenn man nach ewigen Zeiten verzweifelter Suche endlich mal einen BUG findet, der weniger als 1%oo der Nutzer betrifft ... dann müssen auch diese 5 Disketten in 6 umgewandelt werden!

viele Grüsse,
brainstuff

[MC]

> wenn ich subst in der Komandozeile von Windows starte .. und da
erscheint der subst-drive dann im Explorer aber nicht im TC

Refresh-Problem? TC danach neu gestartet?

[Dalai]

Leider hast du weiterhin nicht die Frage beantwortet, mit welchem Nutzer dein TC und das xsubst laufen. Das ist die wichtigste Frage überhaupt, denn wie ich bereits schrieb sind gesubstete Laufwerke nutzerspezifisch - das schließt auch Geschichten wie UAC (Benutzerkontensteuerung) mit ein! D.h. wenn dein TC als Admin gestartet wurde, der Rest aber nicht, ist es logisch, dass TC die gesubsteten Laufwerke nicht kennt.

Die mit dem original subst erzeugten drives kennt nur TC ...Die mit xsubst erzeugten Drives kennt nur der Explorer.

Diese Aussage untermauert meine Vermutung.

Noch eine Sache: Ich hoffe dir ist klar, dass es sich für einen Bug-Report gehört, ein reproduzierbares Szenario zu beschreiben, denn was nicht nachvollziehbar ist, kann auch nicht behoben werden. Das heißt: Schritt für Schritt beschreiben, wie es zu dem Problem/Bug kommt.

MfG Dalai

[brainstuff]

Hallo Dalai,

Du machst mir jetzt ziemlich Angst ... Ich weiss zwar schon seit langer Zeit, dass da irgendjemand mit den Administratoren-Rechten bei MS um die Ecke gedacht hat ... aber das was Du da vermutest wäre dann wirklich der letzte Wahnsinn. Aber vielleicht vermutest Du richtig.

Bei dem betroffenen Computer bin ICH als Admin angemeldet (das ist eine dämliche Einstellung, weil man als Admin, keine Admin Rechte hat. Da der Windows Admi, kein Admin ist ... und weil ich diese blöden Erinnerungen, dass man irgendetwas nur als Admin machen kann (das ist etwas für Smartphone-Streichler), starte ich TC als Administrator.. ich habe es wirklich satt, dass man sich ständig belästigen lassen muss, weil es immer mehr "Smartphone-Streichler" und unbeholfene Computerfreaks gibt.

Der ursprüngliche Grund warum ich TC nur noch im Admin Modus benütze, waren die "Verknüpfungen" auf dem Büro, die man im Normal-Modus nur löschen kann, wenn man auf einen dämlichen Dialog klickt, in dem man gefragt wird, ob man die Verknüpfung, im Admin Modus löschen will ... solche "Verknüpfungen" sind ja, wie wir hier alle wissen ... ein mega wichtiges SICHERHEITSPROBLEM! Ein Wunder, dass man da nicht noch eine Erlaubnis beim Bill Gates und dem US Präsidenten einholen muss.

Was den Ablauf angeht der zum Bug führt ist der ziemlich einfach ... xsubst startet automatisch (es braucht keinen cmd-job, wie bei subst) und legt die eingestellten sub-drives an. Dann startet ein CMD job der deine RAM Disk anlegt (den Drive A) und einen True-crypt container öffnet (= Drive Z). Danach sind dann alle diese Laufwerke im Explorer sichtbar. Dann starte ich TC im Admin Modus (die ini Dateien von TC sind im Drive Z). TC zeigt dann alle Laufwerke an, ausser den subst Laufwerken ... die, wie das jetzt scheint, nur dann von TC erkannt werden, wenn man sie aus der Komandozeile von TC heraus anlegt.

Ich habe nur kurz versucht eine 2. Instanz von TC zu starten (im nicht Admin-Modus) ... das scheint nicht zu gehen, wenn TC schon im Admin-Modus läuft.

Für mich ist es einfach nicht nachvollziehbar, dass TC im Administratoren Modus (in dem es alles machen können sollte) subst-Drives nicht erkennt ...und das wegen dem Admin-Modus.

Danke
viele Grüsse,
brainstuff

[Dalai]

Bei dem betroffenen Computer bin ICH als Admin angemeldet [...]

Die Frage ist nicht, ob du ein Administratorkonto mit Adminrechten benutzt, die Frage ist, wie die UAC eingestellt ist bzw. ob sie ein- oder ausgeschaltet ist. Ist sie eingeschaltet, bekommt ein Nutzer die Adminrechte nur dann, wenn er sie explizit anfordert (z.B. via Kontextmenü "Ausführen als Administrator" oder in den Eigenschaften einer Verknüpfung). Ist sie ausgeschaltet, gibt es (diesbzgl.) keinen Unterschied mehr zu Win2k/XP, d.h. die Mitgliedschaft in einer Nutzergruppe entscheidet über die Adminrechte.

Der ursprüngliche Grund warum ich TC nur noch im Admin Modus benütze, waren die "Verknüpfungen" auf dem Büro, die man im Normal-Modus nur löschen kann, wenn man auf einen dämlichen Dialog klickt, in dem man gefragt wird, ob man die Verknüpfung, im Admin Modus löschen will ... solche "Verknüpfungen" sind ja, wie wir hier alle wissen ... ein mega wichtiges SICHERHEITSPROBLEM!

Es geht hier weniger um ein Sicherheitsproblem sondern um Berechtigungen, also dass ein Admin nun mal mehr darf als ein normaler Benutzer. Und wenn der Admin festlegt, dass bestimmte Dateien von Benutzern nicht verändert werden dürfen, dann ist das eben so und alle haben sich daran zu halten. Oder löschst du fröhlich auf der Arbeit Dateien, die evtl. den Betrieb stören können oder ähnliches? Wohl kaum.

Aber ja, auch die Sicherheit ist ein Kriterium. Stell dir vor, eine Schadsoftware löscht fröhlich Dateien, die systemrelevant sind oder zumindest so wichtig, dass eine Wiederherstellung zusätzliche Arbeit macht. Dazu zählen für mich auch die Verknüpfungen im Startmenü und auf dem Desktop. Ohne Adminrechte kann eine Schadsoftware immer nur das derzeit benutzte Benutzerkonto befallen und zerstören, aber mit Adminrechten kann sie alles anstellen.

Was den Ablauf angeht der zum Bug führt ist der ziemlich einfach

Ich meinte: für jedermann nachvollziehbar und am besten sogar nachstellbar. Klar, das ist nicht immer möglich, weil manchmal Software benutzt wird, die sonst keiner im Einsatz hat. Aber danke für die Erläuterung.

die, wie das jetzt scheint, nur dann von TC erkannt werden, wenn man sie aus der Komandozeile von TC heraus anlegt.

Nein, nicht ganz. Ob Kommandozeile des TC oder nicht, spielt keine Rolle. Entscheidend sind allein die Rechte. Beispiel: Starte aus dem TC heraus eine CMD und subste dort ein Laufwerk und du wirst sehen, dass das Laufwerk auch im TC erscheinen wird.

Ich habe nur kurz versucht eine 2. Instanz von TC zu starten (im nicht Admin-Modus) ... das scheint nicht zu gehen, wenn TC schon im Admin-Modus läuft.

Das trifft nur dann zu, wenn die Einstellung "Nur eine Instanz" aktiviert ist. Sonst kann man natürlich beliebig viele Instanzen starten, solange noch Speicher verfügbar ist.

Für mich ist es einfach nicht nachvollziehbar, dass TC im Administratoren Modus (in dem es alles machen können sollte) subst-Drives nicht erkennt ...und das wegen dem Admin-Modus.

Das mag für dich nicht nachvollziehbar sein, ist aber schon seit Windows 2000 so.

---

Und weil wir gerade wieder beim Thema sind: Ich hoffe dir ist klar, dass es ein Sicherheitsrisiko ist, den TC mit Adminrechten laufen zu lassen. Warum? Nun, jedes Programm, das aus dem TC heraus gestartet wird, bekommt die Rechte vererbt, d.h. hat ebenfalls Adminrechte! Das trifft auch auf Programme zu, die beim Doppelklick auf dessen Dateityp gestartet werden, z.B. Office-Dokumente, Multimedia-Dateien usw. Und übrigens: Auch dort werden deine gesubsteten Laufwerke nicht verfügbar sein, was nebenbei untermauert, dass TC hier keine Schuld trifft.

MfG Dalai

[ZoSTeR]

Neben UAC ist eigentlich der "Integrity Level" entscheidend. Läßt sich mit dem Process Explorer gut erkunden (Integrity Level Spalte einblenden).

D.h. im Falle von Subst sehen Prozesse mit unterschiedlichen "Integrity Levels/en" die Laufwerke des jeweils anderen nicht.

[brainstuff]

@dalai Danke ... jetzt habe ich verstanden woran vieles liegt. Dass TC im Admin Modus die Admin Rechte vererbt, das wusste ich nicht. Das ist der Grund, warum ich (aus dem TC) keine NICHT-Admin TC Instanz öffnen kann. Die bekommt zwangsläufig die Admin Rechte.

Die TC Instanz, ohne Admin Rechte, startet nur vom Explorer aus (oder über eine Verknüpfung auf dem Desktop). In dieser NICHT-Admin Instance von TC sind dann die subst Drives vorhanden, sogar der Drive B ... (auf dem Windows 8.01 Rechner läuft TC (noch) im normalen Modus und hat deshalb auch den Drive B angezeigt.

Ich finde das gar nicht gut, dass TC im Admin-Modus die Admin Rechte an Programme, die man aus TC startet "vererbt" ... TC sollte sich auf die eigenen Rechte beschränken.

Ich verstehe auch nicht, warum TC, die Subst-Drives (die ohne Admin Rechte eingerichtet werden) im Admin-Modus nicht übernimmt ... wenn man diese "Vererbungs-Idee" übernimmt, dann müsste die nächste Sicherheitsstufe (Explorer ist ohne Admin Rechte, TC mit Admin Rechten) die vorherigen (geringeren) Sicherheitseinstellungen übernehmen und deshalb müsste TC auch im Admin Modus die Subst Drives anzeigen...

Ich werde mich jetzt ncht mit Dir streiten, ob das Ganze doch noch ein Bug ist ... aber es sollte doch zu einer kleineren Verbesserung führen ... das Zeichen "^" was den Admin Modus von TC kennzeichnet ist einfach zu klein und zu wenig auffällig ... ich hätte daher gerne, dass zum Besipiel die blaue Diskette auf grauem Hintergrund in der Task-Bar einen roten Rand bekommt, wenn es die Admin-Version von TC ist. Und auch das "^" Zeichen könnte ein grosser roter Punkt sein, damit man ganz klar sieht, dass man in der ADMIN-Version ist ... dann startet man einfach mindestens je eine TC Version im Admin Modus und eine im Normal-Modus .. wenn man viel mit irgendwelchen Arbeiten zu tun hat, die man im Admin-Modus machen will. Und die Vererbung der Admin-Rechte sollte zumindestens abstellbar sein ... weil es nämlich praktisch nie vorkommt, dass man aus TC heraus etwas startet, was Amin Rechte verlangen kann...

Meine tägliche Erfahrung bei Kunden zeigt mir, dass die (wenn sie endlich einmal von der unsinnigen Explorer-Philosophie weggekommen sind .. und zu TC übergewechselt haben), zum Beispiel Word Dateien aus TC heraus starten, oder Bilder ...mit xnview, oder ähnlichem anschauen ... und da braucht es sowieso NIE Admin-Rechte. Selbst Leute wie ich ... die einen haufen Zeug installieren ... haben vielleicht ein paar Programm-Installationen am Tag, wo Admin Rechte verlangt werden .. und wenn ich mich da nicht täusche ... ist TC bei der "Vererbung" der Rechte bei Programminstallationen gar nicht so konsequent ... ich installiere sehr häufig Programme aus TC heraus (klick auf die Installations-Datei) und dann kommt fast immer die Frage, ob das Programm installiert werden darf ... aber ich habe nicht darauf geachtet, ob das was mit den Admin-Rechten zu tun hat.

Wegen diesen Nachfragen bei Programminstallationen habe ich auch nicht gemerkt, dass TC die Admin-Rechte "vererbt".

Die Philosophie, dass man mit den Admin-Rechten, Viren an der Verbreitung hindern kann .. ist für mich Unfug. Wenn ein Nutzer auf ein Installationsprogramm klickt, dann muss er schon ziemlich dämlich sein, wenn er nicht weiss, dass er da etwas installiert ... der klickt dann auch auf das Admin-Frage-ok. Bei uns werden Viren erkannt, bevor sie abgespeichert werden (jedenfalls fast alle .. man weiss ja nie) und von mir aus sind die grössten Gefahren darin zu suchen, dass verblödete Programmierer, ihre Set-up-Dateien mit dem wunderschönen Namen ... "setup.exe" ausstatten. Da weiss dann selbst jemand der sich auskennt, oftmals nicht mehr, was da "setup.exe" installiert ...

Wir gehen in verschiedenen Sachen davon aus, dass wir es mit Vollidioten zu tun haben ... wie beim VERSCHIEBEN von *.LNK Files auf dem Desktop ... die man problemlos wieder zurück schieben kann .. bzw soger problemlos wieder herstellen kann, wenn man sie löscht ... was der "Smartphone-Streichler" sowieso nicht hinbringt. Auf der anderen Seite behandeln wir Leute, die sich auskennen, wie die letzten Idioten.

Ich habe mir übrigens die UAC Rechte-Vergabe angeschaut ... das ist genau so ein System, was man nicht machen sollte ... eine Sicherheitsmassnahme auf eine andere aufsetzen ... das führt nur zu Missverständnissen. In Wirklichkeit hat ein als Administrator angemeldeter Nutzer, genau die gleichen Rechte, wie ein Nutzer, ohne diese Rechte ... er hat lediglich das Recht, diese Grundrechte auszuweiten.

Da TC, im Admin Modus keine Subst-Drives anzeigt, weiss ich jetzt wenigstens, dass der Drive X (mirroir of c ) kein Subst Drive ist. Ein Truecrypt Container ist es auch nicht und auch keine RAM-Disk ... Dalai .. hast Du noch eine Idee, was das sein kann? .. oder ob es vielleicht eine LOG - Datei gibt, wo drin steht was beim Startup dieses komische Laufwerk einrichtet? Ich sehe keinen Grund dafür, den Drive C: noch als Laufwerk X aufzurufen .. zudem kommt es manchmal vor, dass der Drive X nach einem Neustart nicht existiert, er kommt dann auch nicht, bis zum nächsten Neu-Start. (Ich habe sogar in der Registery gesucht .. ich finde nichts was mit diesem Drive zu tun hat).

Danke,
brainstuff

[Dalai]

Ich finde das gar nicht gut, dass TC im Admin-Modus die Admin Rechte an Programme, die man aus TC startet "vererbt" ... TC sollte sich auf die eigenen Rechte beschränken.

Nicht TC ist dafür verantwortlich, dass die Rechte vererbt werden, sondern das System! Jeder Prozess, der von sich aus weitere Prozesse/Programme startet, vererbt die Rechte. Dass da eigentlich noch sogenannte Tokens mit reinspielen und die Rechte anpassbar sind, lass ich mal ganz gekonnt unter den Tisch fallen (nicht aufheben ). Beispiel: Starte eine CMD als Admin und starte von dieser aus irgendein anderes Programm. Ergebnis: alle anderen von dieser CMD aus gestarteten Programme bekommen ebenfalls Adminrechte, mit allen damit verbundenen Rechten, Schwierigkeiten, Besonderheiten (gesubstete und Netzlaufwerke) usw.

Und auf welche eigenen Rechte soll er sich beschränken, wenn er gerade als Admin läuft? Woher soll er andere Rechte nehmen?

Ich verstehe auch nicht, warum TC, die Subst-Drives (die ohne Admin Rechte eingerichtet werden) im Admin-Modus nicht übernimmt

Nicht TC ist dafür verantwortlich, dass diese Rechtetrennung existiert, sondern das System! Das betrifft jede Anwendung. Beispiel: Starte eine CMD, gib dort subst ein, starte eine weitere CMD als Admin und lass dir dort ebenfalls mit subst die Laufwerke anzeigen. Ergebnis: Es gibt Unterschiede.

TC hat weder bei der Rechtetrennung noch bei der Vererbung der Rechte irgendwas mitzureden oder zu beeinflussen. Genauso wenig wie andere Programme da etwas mitzureden haben. Es kann also gar kein Bug im TC sein. Es sind einfach die Gegebenheiten und Sicherheitsmechanismen des Systems.

aber es sollte doch zu einer kleineren Verbesserung führen ... das Zeichen "^" was den Admin Modus von TC kennzeichnet ist einfach zu klein und zu wenig auffällig ... ich hätte daher gerne, dass zum Besipiel die blaue Diskette auf grauem Hintergrund in der Task-Bar einen roten Rand bekommt, wenn es die Admin-Version von TC ist.

Ich glaube, dafür wäre ein eigenes/eigener Thema/Thread angebracht. Deine Idee würde allerdings einen Austausch des Symbols nötig machen. Allerdings frage ich mich, ob das eine Verbesserung ist, denn schaust du wirklich in die Taskleiste, wenn du mit einem Programm arbeitest? Ich nicht. Die Taskleiste kommt bei mir nur in den Fokus, wenn ich zwischen Programmen umschalten will.

Aber du kannst die Sache leicht selbst in die Hand nehmen: lege eine zweite wincmd.ini an, die z.B. andere Farbkombinationen in der Dateiliste benutzt. Diese zweite wincmd.ini kannst du dem TC beim Start übergeben, z.B. durch eine Verknüpfung wie "TC - Admin.lnk" oder sowas. Ist nur eine Anregung.

Die Philosophie, dass man mit den Admin-Rechten, Viren an der Verbreitung hindern kann .. ist für mich Unfug. Wenn ein Nutzer auf ein Installationsprogramm klickt, dann muss er schon ziemlich dämlich sein, wenn er nicht weiss, dass er da etwas installiert

Ach, Schadsoftware kommt bei dir in Form eines Installationsprogramms auf den Rechner? Interessant...
Sorry, aber das ist doch Blödsinn. Der Gag bei Schadsoftware ist doch gerade, dass sie sich möglichst unentdeckt ins System einnisten will - jetzt mal von Adware wie OpenCandy und solchem sch*** abgesehen.

Beispiel: Du bekommst eine Mail mit einem PDF-Anhang (ob gezippt oder nicht, spielt keine Rolle). Dieser Anhang ist verseucht mit irgendeinem Trojaner, der sich ins System einzunisten versucht. Hat man nun keine ausreichenden Rechte dafür, kann er nur im Benutzerprofil Schaden anrichten. Wird dieser Trojaner aber von einem Programm mit Adminrechten aus gestartet, bekommt der Trojaner diese natürlich ebenfalls und kann damit alles machen, was der Admin eben so darf.

Fazit: Eine Rechtetrennung trägt ganz erheblich dazu bei, dass ein System weiterlaufen kann, auch wenn ein Benutzerprofil von Schadsoftware befallen wird. Klar, es gibt dann noch Sicherheitslücken in System und Anwendungssoftware, die eine Rechteausweitung erlaubt, aber genau dafür gibt's ja Windows Updates & Co.

Ich habe mir übrigens die UAC Rechte-Vergabe angeschaut ... das ist genau so ein System, was man nicht machen sollte ... eine Sicherheitsmassnahme auf eine andere aufsetzen ... das führt nur zu Missverständnissen. In Wirklichkeit hat ein als Administrator angemeldeter Nutzer, genau die gleichen Rechte, wie ein Nutzer, ohne diese Rechte ... er hat lediglich das Recht, diese Grundrechte auszuweiten.

Ja, ich mag die UAC auch nicht, weswegen sie auf allen meinen Systemen und denen meiner Kunden deaktiviert wird. Allerdings benutzen alle meine Kunden entsprechende Profile, in denen sie nur Benutzerrechte haben, so dass die Sicherheit gewährleistet bleibt. Zum Installieren von Software können sie ein von mir entwickeltes Programm benutzen, das die Setups mit Adminrechten startet.

Da TC, im Admin Modus keine Subst-Drives anzeigt, weiss ich jetzt wenigstens, dass der Drive X (mirroir of c ) kein Subst Drive ist. Ein Truecrypt Container ist es auch nicht und auch keine RAM-Disk ... Dalai .. hast Du noch eine Idee, was das sein kann? .. oder ob es vielleicht eine LOG - Datei gibt, wo drin steht was beim Startup dieses komische Laufwerk einrichtet?

Schau doch einfach mal in der Datenträgerverwaltung nach, welche Laufwerke dort gelistet werden. Vielleicht gibt das etwas mehr Einblick. Kann aber auch durch irgendeine Software ausgelöst werden, analog zum Laufwerk Q bei MS Office-Installationen.

MfG Dalai