Mal wieder: Rekursive Pfade "Anwendungsdaten\..."

[Christoph Maercker]

Hallo,

... diesmal unter Win2008R2. Welche Rechte mussten zur Behebung nochmal
verweigert werden? Eingestellt sind schon Lesen und "Ordnerinhalte
anzeigen" auf Verweigern für Jeder, direkt für das Verzeichnis
"Anwendungsdaten". Ist allerdings so ein Linkordner und über
"Eigenschaften" nicht erkennbar, wohin er wirklich verweist.

Der Pfad ist \Users\<username>\AppData\Local\Anwendungsdaten\...

Ich nehme stark an, der Nutzer wurde ganz simpel und vorschriftsmäßig
von der Firma angelegt, die den Server installiert hat.
--


CU Christoph Maercker.

[Hans-Peter Matthess]

Christoph Maercker:

> Der Pfad ist \Users\<username>\AppData\Local\Anwendungsdaten\...

Die Junction "Anwendungsdaten" ist kaputt. Sollte so aussehen:
Jeder:(DENY)(S,RD)
NT-AUTORITÄT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
fbi\hpm:(I)(OI)(CI)(F)

Wenn "Jeder:(DENY)(S,RD)" fehlt, kommt es zu den Endlosverschachtelungen im
Explorer. Müsste man also reparieren (Jeder -> Verweigern -> Ordner
auflisten, Daten lesen. Evtl. sind auch die Attribute der Junction
zusätzlich noch kaputt.

> Ich nehme stark an, der Nutzer wurde ganz simpel und vorschriftsmäßig
> von der Firma angelegt, die den Server installiert hat.

Ich weiß nicht, wie die Leute es immer schaffen, diese kaputten Junctions zu
erzeugen. Evtl. Schrottinstallationen durch fehlerhafte Images.

--
Scheinsicherheit und System-Zerstörung durch Virenscanner:
http://www.soehnitz.de/itsicherheit/virenscannersinnoderunsinn/index.html
Darum: http://www.soehnitz.de/itsicherheit/wassiewirklichbrauchen/index.html
Konfiguration einfach gemacht: http://home.arcor.de/skanthak/safer.html

[Christoph Maercker]

Hans-Peter Matthess wrote:
> Die Junction "Anwendungsdaten" ist kaputt. Sollte so aussehen:
> Jeder:(DENY)(S,RD)

Exakt so eingestellt. Was lediglich den Explorer am Zugreifen hindert,
nicht aber andere Programme d.h. die Verweigerung greift seltsamerweise
nicht. Genau so kenne ich es bisher nur in Fällen, wo *keine*
Verweigerung vor Jeder eingetragen war.

> NT-AUTORITÄT\SYSTEM:(I)(OI)(CI)(F)
> VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)

Was in explorerüblicher Darstellung "Vollzugriff" = sämtliche Rechte
erlaubt bedeutet, oder?

> fbi\hpm:(I)(OI)(CI)(F)

Fehlt. Statt dessen ist $user mit Vollzugriff eingetragen.

> Wenn "Jeder:(DENY)(S,RD)" fehlt, kommt es zu den Endlosverschachtelungen im
> Explorer. Müsste man also reparieren (Jeder -> Verweigern -> Ordner
> auflisten, Daten lesen. Evtl. sind auch die Attribute der Junction
> zusätzlich noch kaputt.

Sieht so aus.

>> Ich nehme stark an, der Nutzer wurde ganz simpel und vorschriftsmäßig
>> von der Firma angelegt, die den Server installiert hat.

> Ich weiß nicht, wie die Leute es immer schaffen, diese kaputten Junctions zu
> erzeugen. Evtl. Schrottinstallationen durch fehlerhafte Images.

Nehme ich auch an. Wobei auf dem betr. Server nicht allzuviel in Frage
kommt:

- Acrobat Reader
- 7Zip
- Cisco VPN-Client
- Firefox 6.0 und
- hp OpenView, die Hauptanwendung.

hp-OV ist in Englisch, und scheidet damit als Verursacher weitgehend
aus, dgl. Cisco-VPN.
Außerdem MS-Virtual C++ 2005, das käme natürlich auch als Verursacher in
Frage. ;-)

Mozilla und/oder Adobe legen evtl. die (nicht rekursive) Junction
\Users\<username>\Anwendungsdaten
an, die dann auf
\Users\<username>\AppData\Local\
verweist. Wer dort drin nochmals "Anwendungsdaten" anlegt und wozu, weiß
der Geier. Die AppDaten der beiden o.g. Progs liegen Z.Zt. nur beim User
\Users\Administrator\AppData\Local\
an Der hat ebenfalls das o.g. rekursive Verzeichnis "Anwendungsdaten",
unter \Program Data habe ich eben noch eins gefunden. Die "Installer"
leisten mal wieder ganze Arbeit. :-\

BTW: Kann in den Userprofilen ein *echtes* Verzeichnis "Anwendungsdaten"
angelegt werden oder verhindert Win7 das? Sonst hieße das, die
Programmierer mind. einer der o.g. Anwendung hätten zwar mal was von
Junctions gehört und sie in ihren Installern beigebracht, welche
anzulegen, kennen deren Funktionsweise aber ebenso wenig wie die meisten
Windows-Nutzer. Ältere Installer, die das Junction-Konzept noch nicht
kennen, würden ja versuchen, die betr. Verzeichnisse in echt anzulegen.
Falls sie nicht schlau genug sind, die betr. Systemvariable abzufragen
und das machen meiner Erfahrung nach ziemlich viele nicht.
--


CU Christoph Maercker.

[Christoph Maercker]

Christoph Maercker wrote:
> ... diesmal unter Win2008R2.

> Eingestellt sind für das Verzeichnis "Anwendungsdaten" Lesen und "Ordnerinhalte anzeigen" auf Verweigern für Jeder,

> Pfad ist \Users\<username>\AppData\Local\Anwendungsdaten\...

Es ist noch verrückter als ich dachte:
1. Jeder wird Read+FileScan verweigert: klappt
2. Die Rekursionen hören scheinbar auf
3. Wechsel in beliebiges anderes Verzeichnis
4. CD $ursprungsverzeichnis: Rekursionen sind wieder da!
5. Überprüfung Berechtigungen: Anzeige wird verweigert!!
6. Besitzübernahme durch Administratoren: klappt
7. Anzeige Berechtigungen: klappt, RS stehr für Jeder auf Verweigern

Warum 5. passiert ist klar, aber wieso man mit beliebigen Programmen
außer Explorer in die nunmehr angeblich gesperrten Verzeichnisse weiter
rekursiv öffnen kann, ist das Rätsel.
--


CU Christoph Maercker.

[Hans-Peter Matthess]

Christoph Maercker:

> Hans-Peter Matthess wrote:
>> Die Junction "Anwendungsdaten" ist kaputt. Sollte so aussehen:
>> Jeder:(DENY)(S,RD)

> Exakt so eingestellt. Was lediglich den Explorer am Zugreifen hindert,

Dann ist es ja ok. Es hindert alle Programme an dem in der Verweigerung
eingestellten Zugriff, nicht nur den Explorer.

> nicht aber andere Programme d.h. die Verweigerung greift seltsamerweise
> nicht.

Doch, die Verweigerung greift natürlich für alle anderen Programme auch,
was eben *genau diese Verweigerung" betrifft. Es hindert Programme
allerdings nicht daran, zum Ziel der Junction zu springen, sonst würde die
Junction ja nicht funktionieren. Einige Dateimanager machen das auch so.
Sie können die Junction ebenfalls nicht öffnen, wie auch der Explorer, aber
sie zeigen das Ziel an. Welche "Anderen Programme" sind das denn und was
genau passiert da? Welche Fehler zeigen sich?

> Genau so kenne ich es bisher nur in Fällen, wo *keine*
> Verweigerung vor Jeder eingetragen war.

Du bist im Moment nur etwas verwirrt. ;-)

>> NT-AUTORITÄT\SYSTEM:(I)(OI)(CI)(F)
>> VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)

> Was in explorerüblicher Darstellung "Vollzugriff" = sämtliche Rechte
> erlaubt bedeutet, oder?

Ja

>> fbi\hpm:(I)(OI)(CI)(F)

> Fehlt. Statt dessen ist $user mit Vollzugriff eingetragen.

Nö, hpm ist ja $user, mein Useraccount.

> Mozilla und/oder Adobe legen evtl. die (nicht rekursive) Junction
> \Users\<username>\Anwendungsdaten
> an, die dann auf
> \Users\<username>\AppData\Local\
> verweist. Wer dort drin nochmals "Anwendungsdaten" anlegt und wozu, weiß
> der Geier.

Nö, all diese Junctions werden vom Windows-Setup bei der Installation
eingerichtet. Programme legen keine an.

> BTW: Kann in den Userprofilen ein *echtes* Verzeichnis "Anwendungsdaten"
> angelegt werden oder verhindert Win7 das?

Wenn man die gleichnamige Junction löscht, kann man das, aber das wäre doch
grober Unfug. %Appdata% existiert doch.

> Sonst hieße das, die
> Programmierer mind. einer der o.g. Anwendung hätten zwar mal was von
> Junctions gehört und sie in ihren Installern beigebracht, welche
> anzulegen,

Wie gesagt, ich kenne keine Anwendung, die Junctions erzeugt.

> kennen deren Funktionsweise aber ebenso wenig wie die meisten
> Windows-Nutzer. Ältere Installer, die das Junction-Konzept noch nicht
> kennen, würden ja versuchen, die betr. Verzeichnisse in echt anzulegen.
> Falls sie nicht schlau genug sind, die betr. Systemvariable abzufragen
> und das machen meiner Erfahrung nach ziemlich viele nicht.

Die Junctions sind ja aus Gründen der Abwärtskompatibilität da.
Wenn ein altes Programm fest auf "Anwendungsdaten" verdrahtet ist, wird es
von der Junction an den richtigen Ort umgeleitet. Im Grunde kann man die
Junctions alle löschen. Die Programme, die dann nicht mehr funktionieren,
sind kaputter Schrott. Durch aktuelle ersetzen.

[Christoph Maercker]

Hans-Peter Matthess wrote:
> Dann ist es ja ok. Es hindert alle Programme an dem in der Verweigerung
> eingestellten Zugriff, nicht nur den Explorer.

In den Fällen, wo ich bisher die Rechte so eingestellt habe, ja.

> Doch, die Verweigerung greift natürlich für alle anderen Programme auch,
> was eben *genau diese Verweigerung" betrifft. Es hindert Programme
> allerdings nicht daran, zum Ziel der Junction zu springen, sonst würde die
> Junction ja nicht funktionieren. Einige Dateimanager machen das auch so.
> Sie können die Junction ebenfalls nicht öffnen, wie auch der Explorer, aber
> sie zeigen das Ziel an. Welche "Anderen Programme" sind das denn und was
> genau passiert da? Welche Fehler zeigen sich?

Die Rekursionen bleiben bzw. kommen wieder, sobald ich das Verzeichnis
nach $irgendwohin wechsle und wieder zurückkehre. Siehe mein
Parallelbeitrag von Freitag <j4vl8v$d1b$1...@fuerst.cs.uni-magdeburg.de>.

>> Genau so kenne ich es bisher nur in Fällen, wo *keine*
>> Verweigerung vor Jeder eingetragen war.

> Du bist im Moment nur etwas verwirrt. ;-)

Hm, auf meinem Dienst-PC hatte ich Junctions, die Rekursionen erzeugt
haben, kurzerhand mit Sysinternals Junction.exe gelöscht, bisher ohne
ärgerliche Nebenwirkungen. Auf dem Home-PC habe ich die Rechte geändert:

>>> NT-AUTORITÄT\SYSTEM:(I)(OI)(CI)(F)
>>> VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)

Auch damit bin ich die Rekursionen losgeworden. Auf dem 2008-System
bleiben die Rekursionen, trotz verweigerter Rechte.

> Nö, all diese Junctions werden vom Windows-Setup bei der Installation
> eingerichtet. Programme legen keine an.

Ändern aber evtl. die Rechte? Sonst wüsste ich nicht, wie es zu den
rekursiven Verzeichnissen kommen kann, es sei denn, der
Windows-Installer produziert sie unter bestimmten Bedingungen.

>> BTW: Kann in den Userprofilen ein *echtes* Verzeichnis "Anwendungsdaten"
>> angelegt werden oder verhindert Win7 das?
> Wenn man die gleichnamige Junction löscht, kann man das, aber das wäre doch
> grober Unfug. %Appdata% existiert doch.

Natürlich, aber Installer, die noch keine Junctions kennen, würden evtl.
genau das machen. Beileibe nicht alle sind so schlau, %AppData% zu
verwenden:

> Die Junctions sind ja aus Gründen der Abwärtskompatibilität da.
> Wenn ein altes Programm fest auf "Anwendungsdaten" verdrahtet ist, wird es
> von der Junction an den richtigen Ort umgeleitet. Im Grunde kann man die
> Junctions alle löschen. Die Programme, die dann nicht mehr funktionieren,
> sind kaputter Schrott. Durch aktuelle ersetzen.

Leuchtet ein. Auf dem W2008-Server, um den es geht, kann ich die
Junctions mit gutem Gewissen killen, dort wird nur eine wichtige und
aktuelle Anwendung laufen. Muss zum Löschen von Junctions so was wie das
o.g. Tool von Sysinternals verwendet werden? Einfach mit DEL-Taste
kriegt man sie WIMRE nicht weg.
--


CU Christoph Maercker.

[Hans-Peter Matthess]

Christoph Maercker:

>> Dann ist es ja ok. Es hindert alle Programme an dem in der Verweigerung
>> eingestellten Zugriff, nicht nur den Explorer.

> In den Fällen, wo ich bisher die Rechte so eingestellt habe, ja.

Die Junctions haben aber alle identische Rechte. Wenn man erst etwas
einstellen muss, ist schon der Wurm drin.

>> Doch, die Verweigerung greift natürlich für alle anderen Programme auch,
>> was eben *genau diese Verweigerung" betrifft. Es hindert Programme
>> allerdings nicht daran, zum Ziel der Junction zu springen, sonst würde die
>> Junction ja nicht funktionieren. Einige Dateimanager machen das auch so.
>> Sie können die Junction ebenfalls nicht öffnen, wie auch der Explorer, aber
>> sie zeigen das Ziel an. Welche "Anderen Programme" sind das denn und was
>> genau passiert da? Welche Fehler zeigen sich?

> Die Rekursionen bleiben bzw. kommen wieder, sobald ich das Verzeichnis
> nach $irgendwohin wechsle und wieder zurückkehre. Siehe mein
> Parallelbeitrag von Freitag <j4vl8v$d1b$1...@fuerst.cs.uni-magdeburg.de>.

Ja, das ist mir allerdings zu allgemein und nebulös gehalten. Nichts, was
man exakt nachvollziehen könnte. Ich kann weder in Anwendungen noch in
der Konsole Rekursionen erzeugen. Ich hatte ja schon mal nach einer exakt
nachvollziehbaren Befehlsfolge gefragt.

>>> Genau so kenne ich es bisher nur in Fällen, wo *keine*
>>> Verweigerung vor Jeder eingetragen war.

>> Du bist im Moment nur etwas verwirrt. ;-)

> Hm, auf meinem Dienst-PC hatte ich Junctions, die Rekursionen erzeugt
> haben, kurzerhand mit Sysinternals Junction.exe gelöscht,

Ein Klick auf "Löschen" tut's auch.

> bisher ohne
> ärgerliche Nebenwirkungen.

Eben, einfach weg damit, Problem erledigt. ;-)

>> Nö, all diese Junctions werden vom Windows-Setup bei der Installation
>> eingerichtet. Programme legen keine an.

> Ändern aber evtl. die Rechte?

Wenn es ein Programm gäbe, das sowas machte, müsste dieses nach Löschen der
Junction ja eigentlich nicht mehr funktionieren.

[Christoph Maercker]

Hans-Peter Matthess wrote:
> Die Junctions haben aber alle identische Rechte. Wenn man erst etwas
> einstellen muss, ist schon der Wurm drin.

Die Rechte scheinen sogar zu stimmen, alle Verzeichnisse, die ich
überprüft hatte waren für Jeder zum Lesen und Scannen gesperrt. Trotzdem
können Anwendungen, WIMRE sogar cmd.exe in diese Junctions bis zur
Unendlichkeit reinschauen.

>> Die Rekursionen bleiben bzw. kommen wieder, sobald ich das Verzeichnis
>> nach $irgendwohin wechsle und wieder zurückkehre. Siehe mein
>> Parallelbeitrag von Freitag<j4vl8v$d1b$1...@fuerst.cs.uni-magdeburg.de>.

> Ja, das ist mir allerdings zu allgemein und nebulös gehalten. Nichts, was
> man exakt nachvollziehen könnte. Ich kann weder in Anwendungen noch in
> der Konsole Rekursionen erzeugen. Ich hatte ja schon mal nach einer exakt
> nachvollziehbaren Befehlsfolge gefragt.

Beantwortet hatte ich Deine Frage mit Verzeichnisauszügen, z.B. am
01.07., generiert mit windowseigener cmd.exe:

z.B. hier:
Datenträger in Laufwerk C: ist xxx
Verzeichnis von c:\Users\All
Users\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\ ...

29.04.2011 14:54 <DIR> Adobe
06.04.2011 14:42 <DIR> Windows Genuine Advantage

Genauso sieht es momentan auf dem W2008-Server aus, trotz korrekt
gesetzter Rechte. Und es sind wie Du siehst nicht nur Fremdprogramme,
sondern auch M$-eigene, die solche Rekursionen produzieren.

> Ein Klick auf "Löschen" tut's auch.

Im Explorer, wohlgemerkt. Andere Filemanager verrecken an den Rekursionen.

> Eben, einfach weg damit, Problem erledigt. ;-)

Auf dem W2008-System habe ich es inzwischen so gemacht.

>>> Nö, all diese Junctions werden vom Windows-Setup bei der Installation
>>> eingerichtet. Programme legen keine an.
>
>> Ändern aber evtl. die Rechte?
>
> Wenn es ein Programm gäbe, das sowas machte, müsste dieses nach Löschen der
> Junction ja eigentlich nicht mehr funktionieren.

Würde mich nicht wundern. Ist bisher aber noch nicht passiert und wird
auf dem 2008er hoffentlich auch nicht.
--


CU Christoph Maercker.

[Hans-Peter Matthess]

Christoph Maercker:

> Hans-Peter Matthess wrote:
>> Die Junctions haben aber alle identische Rechte. Wenn man erst etwas
>> einstellen muss, ist schon der Wurm drin.

> Die Rechte scheinen sogar zu stimmen, alle Verzeichnisse, die ich
> überprüft hatte waren für Jeder zum Lesen und Scannen gesperrt. Trotzdem
> können Anwendungen, WIMRE sogar cmd.exe in diese Junctions bis zur
> Unendlichkeit reinschauen.

Nur in der Form, wie von Melanchthon hier beschrieben:
http://blogs.technet.com/dmelanchthon/archive/2006/11/24/kein-zugriff-auf-verzeichnisse-unter-windows-vista.aspx

>>> Die Rekursionen bleiben bzw. kommen wieder, sobald ich das Verzeichnis
>>> nach $irgendwohin wechsle und wieder zurückkehre. Siehe mein
>>> Parallelbeitrag von Freitag<j4vl8v$d1b$1...@fuerst.cs.uni-magdeburg.de>.

>> Ja, das ist mir allerdings zu allgemein und nebulös gehalten. Nichts, was
>> man exakt nachvollziehen könnte. Ich kann weder in Anwendungen noch in
>> der Konsole Rekursionen erzeugen. Ich hatte ja schon mal nach einer exakt
>> nachvollziehbaren Befehlsfolge gefragt.

> Beantwortet hatte ich Deine Frage mit Verzeichnisauszügen, z.B. am
> 01.07., generiert mit windowseigener cmd.exe:
>
> z.B. hier:
> Datenträger in Laufwerk C: ist xxx
> Verzeichnis von c:\Users\All
> Users\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\ ...
>
> 29.04.2011 14:54 <DIR> Adobe
> 06.04.2011 14:42 <DIR> Windows Genuine Advantage

Ja, aber da fehlt schon wieder der von mir NACHVOLLZIEHBARE BEFEHL, der
obige Ausgabe erzeugte. ;-) Ich muss doch, um etwas nachvollziehen zu
können, erstens wissen, wo ich mich befinde und zweitens wissen, was ich
eingeben soll. Beispiel hier:

Ich befinde mich in "C:\Users\hpm\AppData\Local" und gebe da ein:
"dir Anwendungsdaten"
-------------------------------
C:\Users\hpm\AppData\Local>dir Anwendungsdaten
Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten
Datei nicht gefunden
-------------------------------------
Also keine Rekursion, sondern "Datei nicht gefunden".
Ein Blick direkt in "Anwendungsdaten" geht nicht.
Da aber die Junction "Anwendungsdaten" auf das Verzeichnis zeigt, in dem sie
sich befindet, klappt dies hier:
"dir Anwendungsdaten\Microsoft"
------------------------------------
C:\Users\hpm\AppData\Local>dir Anwendungsdaten\Microsoft
Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten\Microsoft
17.09.2011 12:50 <DIR> .
17.09.2011 12:50 <DIR> ..
19.10.2009 18:06 <DIR> Assistance
19.09.2011 19:16 <DIR> Device Metadata
19.10.2009 15:12 <DIR> Event Viewer
12.09.2011 18:47 <DIR> Feeds
usw...
---------------------------------------
Die Junction funktioniert also wie erwartet.
Von der Ebene aus wäre "Dir Microsoft" natürlich einfacher gewesen.

>> Ein Klick auf "Löschen" tut's auch.

> Im Explorer, wohlgemerkt. Andere Filemanager verrecken an den Rekursionen.

Welcher Filemanager denn z.B.? Ich habe hier etliche parat, bei keinem
Rekursionen. Moderne Dateimanager springen entweder zum Ziel der Junction,
was keine Rekursionen ergibt oder bringen ein "Zugriff verweigert" wie der
Windows-Explorer.

[Christoph Schmees]

Am 2011-09-20 11:08, schrieb Christoph Maercker:
> ...

> z.B. hier:
> Datenträger in Laufwerk C: ist xxx
> Verzeichnis von c:\Users\All
> Users\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\
> ...
>
> 29.04.2011 14:54 <DIR> Adobe
> 06.04.2011 14:42 <DIR> Windows Genuine Advantage
>
> Genauso sieht es momentan auf dem W2008-Server aus, trotz korrekt
> gesetzter Rechte. Und es sind wie Du siehst nicht nur
> Fremdprogramme, sondern auch M$-eigene, die solche Rekursionen
> produzieren.
>
>> Ein Klick auf "Löschen" tut's auch.
>
> Im Explorer, wohlgemerkt. Andere Filemanager verrecken an den
> Rekursionen.

> ...

mir ging es genau andersherum: Ich habe schon mehrere
Vista-Rechner hier gehabt, weil sie herummuckelten - u.a. wegen
dieser Rekursionen, wie sich dann herausstellte. Und der
hauseigene Explorer verschluckte sich entweder selbst oder konnte
sie nicht handhaben. Ich konnte das mit einem fremden Commander
lösen.

Christoph

--
email:
nurfuerspam -> gmx
de -> net

[Christoph Maercker]

Hans-Peter Matthess wrote:
> Nur in der Form, wie von Melanchthon hier beschrieben:
> http://blogs.technet.com/dmelanchthon/archive/2006/11/24/kein-zugriff-auf-verzeichnisse-unter-windows-vista.aspx

Danke, sehe ich mir morgen an.

>> Datenträger in Laufwerk C: ist xxx
>> Verzeichnis von c:\Users\All
>> Users\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\ ...

...

> Ja, aber da fehlt schon wieder der von mir NACHVOLLZIEHBARE BEFEHL,

in einer DOS-Box dachte ich, wäre das klar:

> Ich befinde mich in "C:\Users\hpm\AppData\Local" und gebe da ein:
> "dir Anwendungsdaten"
> -------------------------------
> C:\Users\hpm\AppData\Local>dir Anwendungsdaten
> Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten
> Datei nicht gefunden
> -------------------------------------
> Also keine Rekursion, sondern "Datei nicht gefunden".

Just so habe ich obigen Output produziert:
cd anwend*
cd anwend*
cd anwend*
cd anwend*
...
dir anwend* > dir.txt

> Ein Blick direkt in "Anwendungsdaten" geht nicht.

Auf "befallenen" System geht der sehr gut. ;-)

> Da aber die Junction "Anwendungsdaten" auf das Verzeichnis zeigt, in dem sie
> sich befindet, klappt dies hier:
> "dir Anwendungsdaten\Microsoft"
> ------------------------------------
> C:\Users\hpm\AppData\Local>dir Anwendungsdaten\Microsoft
> Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten\Microsoft
> 17.09.2011 12:50<DIR> .
> 17.09.2011 12:50<DIR> ..
> 19.10.2009 18:06<DIR> Assistance
> 19.09.2011 19:16<DIR> Device Metadata
> 19.10.2009 15:12<DIR> Event Viewer
> 12.09.2011 18:47<DIR> Feeds
> usw...
> ---------------------------------------
> Die Junction funktioniert also wie erwartet.

Stimmt so würde ich es erwarten. Auf meinem Home-PC überprüfe ich das
dieser Tage mal. Dort gab es zumindest an dem Tag als ich die Rechte für
Jeder verweigert hatte, keine Rekursionen mehr.

>> Im Explorer, wohlgemerkt. Andere Filemanager verrecken an den Rekursionen.

> Welcher Filemanager denn z.B.? Ich habe hier etliche parat, bei keinem
> Rekursionen. Moderne Dateimanager springen entweder zum Ziel der Junction,
> was keine Rekursionen ergibt oder bringen ein "Zugriff verweigert" wie der
> Windows-Explorer.

z.B. Total Commander v7.50a, aber bei Systemen, wo es auftritt, eben
auch CMD.exe. Als ich auf dem 2008-Server in einem der betr.
Verzeichnisse "DEL /S Anwendungsdaten" eingegeben habe, kam prompt die
Frage, ob auch das gleichnamige Unterverzeichnis gelöscht werden soll.
Ich habe an der Stelle sicherheitshalber mit "n" geantwortet.
--


CU Christoph Maercker.

[Christoph Maercker]

Christoph Schmees wrote:
> mir ging es genau andersherum: Ich habe schon mehrere Vista-Rechner hier
> gehabt, weil sie herummuckelten - u.a. wegen dieser Rekursionen, wie
> sich dann herausstellte. Und der hauseigene Explorer verschluckte sich
> entweder selbst oder konnte sie nicht handhaben. Ich konnte das mit
> einem fremden Commander lösen.

Könnte gut sein, der Mista-Explorer kommt mit den Junctions auch noch
nicht klar und M$ hat mit Win7 wenigstens die Darstellung gefixt.
--


CU Christoph Maercker.

[Hans-Peter Matthess]

Christoph Maercker:

>>> Users\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\ ...
> ...

>> Ja, aber da fehlt schon wieder der von mir NACHVOLLZIEHBARE BEFEHL,

> in einer DOS-Box dachte ich, wäre das klar:

Da kann man aber jede Menge netter Befehle eingeben. Hätte ja auch etwas
mit dir /s... sein können...

>> Ich befinde mich in "C:\Users\hpm\AppData\Local" und gebe da ein:
>> "dir Anwendungsdaten"
>> -------------------------------
>> C:\Users\hpm\AppData\Local>dir Anwendungsdaten
>> Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten
>> Datei nicht gefunden
>> -------------------------------------
>> Also keine Rekursion, sondern "Datei nicht gefunden".

> Just so habe ich obigen Output produziert:
> cd anwend*
> cd anwend*
> cd anwend*
> cd anwend*

Das ist klar, das kann man beliebig treiben, ist auch durch Rechte nicht
untersagt, fragt sich allerdings, warum man sowas Sinnloses tun sollte.
In keinem der Anwend* kann irgendwas angezeigt werden.
...
> dir anwend* > dir.txt

Da kommt dann halt immer "Datei nicht gefunden".

>> Ein Blick direkt in "Anwendungsdaten" geht nicht.

> Auf "befallenen" System geht der sehr gut. ;-)

Ich dachte jetzt, du hättest eine Möglichkeit gefunden, auf Systemen mit
korrekten Junctions nachvollziehbar Rekursionen zu erzeugen.
Das obige Spiel mit "cd anwend*" ist zwar sowas, ich kenne aber kein
Programm oder keinen User, der sowas machen würde.
Ein "dir" direkt in Anwendungsdaten bringt halt kein Ergebnis, egal, wie oft
man es versucht. Nur mit kaputter Junction geht das.

>> Da aber die Junction "Anwendungsdaten" auf das Verzeichnis zeigt, in dem sie
>> sich befindet, klappt dies hier:
>> "dir Anwendungsdaten\Microsoft"
>> ------------------------------------
>> C:\Users\hpm\AppData\Local>dir Anwendungsdaten\Microsoft
>> Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten\Microsoft
>> 17.09.2011 12:50<DIR> .
>> 17.09.2011 12:50<DIR> ..
>> 19.10.2009 18:06<DIR> Assistance
>> 19.09.2011 19:16<DIR> Device Metadata
>> 19.10.2009 15:12<DIR> Event Viewer
>> 12.09.2011 18:47<DIR> Feeds
>> usw...
>> ---------------------------------------
>> Die Junction funktioniert also wie erwartet.

> Stimmt so würde ich es erwarten. Auf meinem Home-PC überprüfe ich das
> dieser Tage mal. Dort gab es zumindest an dem Tag als ich die Rechte für
> Jeder verweigert hatte, keine Rekursionen mehr.

OK

>>> Im Explorer, wohlgemerkt. Andere Filemanager verrecken an den Rekursionen.

>> Welcher Filemanager denn z.B.? Ich habe hier etliche parat, bei keinem
>> Rekursionen. Moderne Dateimanager springen entweder zum Ziel der Junction,
>> was keine Rekursionen ergibt oder bringen ein "Zugriff verweigert" wie der
>> Windows-Explorer.

> z.B. Total Commander v7.50a, aber bei Systemen, wo es auftritt, eben
> auch CMD.exe.

Der TC (hier 7.56a) springt immer zum Ziel, versucht nicht, die Junction zu
öffnen. Wenn man da auf "Anwendungsdaten" doppelklickt, tut sich gar nichts,
denn die Junction zeigt halt auf das Verzeichnis, in dem sie sich befindet
und das ja eh gerade schon angezeigt wird.
Beim Doppelklick auf "Dokumente und Einstellungen" springt er z.B. nach
"C:\Users". Ist die Junction kaputt, ist das Ergebnis aber
"C:\Dokumente und Einstellungen".

> Als ich auf dem 2008-Server in einem der betr.
> Verzeichnisse "DEL /S Anwendungsdaten" eingegeben habe, kam prompt die
> Frage, ob auch das gleichnamige Unterverzeichnis gelöscht werden soll.
> Ich habe an der Stelle sicherheitshalber mit "n" geantwortet.

Bei korrekter Junction kommt da wieder "nicht gefunden".

[Hans-Peter Matthess]

Christoph Schmees:

>> Im Explorer, wohlgemerkt. Andere Filemanager verrecken an den
>> Rekursionen.

> mir ging es genau andersherum: Ich habe schon mehrere
> Vista-Rechner hier gehabt, weil sie herummuckelten - u.a. wegen
> dieser Rekursionen, wie sich dann herausstellte. Und der
> hauseigene Explorer verschluckte sich entweder selbst oder konnte
> sie nicht handhaben. Ich konnte das mit einem fremden Commander
> lösen.

Wenn die Leute unsachgemäß daran rumbasteln, ist das kein Wunder.
Die sollen die Pfoten davon lassen, dann verschluckt sich auch niemand.

[Christoph Maercker]

Hans-Peter Matthess wrote:
>> cd anwend*
>> cd anwend*
>> cd anwend*
>> cd anwend*
>
> Das ist klar, das kann man beliebig treiben, ist auch durch Rechte nicht
> untersagt, fragt sich allerdings, warum man sowas Sinnloses tun sollte.

Diverse Datei-Suchprogramme scheinen es zu tun(, weil sie die Junctions
rekursiv sehen). Ohne die hätte ich den Bug gar nicht bemerkt.
Gelegentlich teste ich mal einen x-beliebigen Packer.

> In keinem der Anwend* kann irgendwas angezeigt werden.

Das schon, nur die Junctions werden mit DIR nicht mehr angezeigt, das
stimmt.

...
>> dir anwend*> dir.txt

> Da kommt dann halt immer "Datei nicht gefunden".

Bei verkürzten Verzeichnisnamen ja, nicht aber wenn er vollständig
angegeben wird:

j:\Users\weston\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten>dir
anw*
Verzeichnis von
j:\Users\user\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten

Datei nicht gefunden

j:\Users\weston\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten>dir
anwendungsdaten

Verzeichnis von
j:\Users\user\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\anwendungsdaten

22.09.2011 08:53 <DIR> .
22.09.2011 08:53 <DIR> ..
30.06.2011 10:53 <DIR> Adobe
15.09.2011 09:16 <DIR> assembly
15.09.2011 09:16 <DIR> Microsoft
27.05.2011 07:40 <DIR> Microsoft Help
29.06.2011 16:47 <DIR> MiKTeX
04.08.2011 15:47 7.595 Resmon.ResmonCfg
...

>>> Ein Blick direkt in "Anwendungsdaten" geht nicht.
>
>> Auf "befallenen" System geht der sehr gut. ;-)
>
> Ich dachte jetzt, du hättest eine Möglichkeit gefunden, auf Systemen mit
> korrekten Junctions nachvollziehbar Rekursionen zu erzeugen.
> Das obige Spiel mit "cd anwend*" ist zwar sowas, ich kenne aber kein
> Programm oder keinen User, der sowas machen würde.

Dann dürften sich Dateisuchen, z.B. mit Total Commander nicht in solchen
Pseudo-Verzeichnisbäumen festfahren. Anscheindend sehen die bei einem
simplen Directory Scan mehr als DIR, sonst würden sie die rekursiven
Unterverzeichnisse nicht finden.

> Ein "dir" direkt in Anwendungsdaten bringt halt kein Ergebnis, egal, wie oft
> man es versucht. Nur mit kaputter Junction geht das.

Demnach wäre die Junction auf dem oben "zitierten" System in Ordnung.
Blankes DIR zeigt die Junctions auch dort nur auf oberster Ebene an.

>> z.B. Total Commander v7.50a, aber bei Systemen, wo es auftritt, eben
>> auch CMD.exe.
>
> Der TC (hier 7.56a) springt immer zum Ziel, versucht nicht, die Junction zu
> öffnen. Wenn man da auf "Anwendungsdaten" doppelklickt, tut sich gar nichts,
> denn die Junction zeigt halt auf das Verzeichnis, in dem sie sich befindet
> und das ja eh gerade schon angezeigt wird.

Auf manchen Systemen ja, auf anderen nicht. Auf dem 2008-System, um das
es im OP geht, jeweils nach dem Verweigern von Directory Scan, solange
das Verzeichnis nicht nach oben verlassen wurde.

> Beim Doppelklick auf "Dokumente und Einstellungen" springt er z.B. nach
> "C:\Users". Ist die Junction kaputt, ist das Ergebnis aber
> "C:\Dokumente und Einstellungen".

Stimmt, das habe ich bisher vergessen zu erwähnen: Die Rekursionen
wurden bisher ausschließlich bei "Anwendungsdaten" und "App Data"
beobachtet. Andere Junctions verhalten sich in der DOS-Box wie auch im
TC exakt so, wie ich erwarten würde und wie $Anwendungsgeraffel auf
manchen Systemen ebenfalls funktioniert:

cd \programme
j:\Programme>cd \programme
j:\Programme>cd \programme
j:\Programme>cd \programme
j:\Programme>
...

Allerdings sind die Berechtigungen von "Programme" etwas anders als bei
$Anwendungsgeraffel gesetzt:
"Ordnerinhalt auflisten/Lesen" unter "Spezielle Berechtigungen" wird
verweigert. Ich hatte bei $Anwendungsgeraffel die allgemein zugänglichen
Berechtigungen "Ordnerinhalt auflisten" + "Lesen" verweigert. Worin
besteht der Unterschied??

>> Als ich auf dem 2008-Server in einem der betr.
>> Verzeichnisse "DEL /S Anwendungsdaten" eingegeben habe, kam prompt die
>> Frage, ob auch das gleichnamige Unterverzeichnis gelöscht werden soll.
>> Ich habe an der Stelle sicherheitshalber mit "n" geantwortet.

> Bei korrekter Junction kommt da wieder "nicht gefunden".

Bei diesem System hat sich's durch Löschen per Commander erledigt. Beim
nächsten probiere ich mal, ob die "speziellen" den entscheidenden
Unterschied ausmachen.

BTW: Wieviele Admins blicken bei den NTFS-Rechten einklich durch? Wenn
ich das mit den schlappen 7+1 Rechten unter NetWare oder gar den 3x3
Rechten unter Linux/Unix vergleiche ... weil es doch immer heißt,
Windows wäre so einfach zu bedienen ...
Die Frage, ob auch User die NTFS-Rechte beherrschen, erübrigt sich schon
beinahe.
--


CU Christoph Maercker.

[Robert Jasiek]

Christoph Maercker wrote:
>Wieviele Admins blicken bei den NTFS-Rechten einklich durch?

Vermutlich fast niemand. War es Paul Thurrott, der schrieb, dass er 2
Jahre lang NTFS-Rechte studiert hätte, nur um dann einzusehen, dass
man sich besser auf die grundlegenden Lese-, Schreib- und
Ausführungsrechte beschränken solle?

[Christoph Schmees]

Am 2011-09-22 10:02, schrieb Christoph Maercker:
> ...

>
> BTW: Wieviele Admins blicken bei den NTFS-Rechten einklich durch?
> Wenn ich das mit den schlappen 7+1 Rechten unter NetWare oder gar
> den 3x3 Rechten unter Linux/Unix vergleiche ... weil es doch
> immer heißt, Windows wäre so einfach zu bedienen ...
> Die Frage, ob auch User die NTFS-Rechte beherrschen, erübrigt
> sich schon beinahe.

das "beinahe" kannst du getrost weglassen :-)

[Heisenberg und Planck diskutieren über die Unschärfe-Relation.
Planck meint, auf der ganzen Welt hätten nur drei Menschen die
Unschärfe-Relation verstanden. Darauf Heisenberg: Wer ist der
dritte?]

Wobei wir nicht ausschließen wollen, dass der eine oder andere
MCSE sich *tatsächlich* im NTFS-Rechte-Dschungel einigermaßen
zurecht findet.

[Hans-Peter Matthess]

Christoph Maercker:

> Hans-Peter Matthess wrote:
>>> cd anwend*
>>> cd anwend*
>>> cd anwend*
>>> cd anwend*

>> Das ist klar, das kann man beliebig treiben, ist auch durch Rechte nicht
>> untersagt, fragt sich allerdings, warum man sowas Sinnloses tun sollte.

> Diverse Datei-Suchprogramme scheinen es zu tun(, weil sie die Junctions
> rekursiv sehen). Ohne die hätte ich den Bug gar nicht bemerkt.
> Gelegentlich teste ich mal einen x-beliebigen Packer.

Das ist so ähnlich wie mit den "diversen Dateimanagern". Ich hab immer
noch keinen gefunden, der da Mist baut. Es ist z.B. der Name "TC" gefallen,
der macht sowas hier aber nachvollziehbar nicht, sondern verhält sich korrekt.
Gibt es ein bestimmtes Suchprogramm, mit dem sich das nachvollziehen lässt?
Es kann jedenfalls kein Programm eine gesetzte Verweigerung ignorieren.
Das wäre ein glattes Wunder.

>> In keinem der Anwend* kann irgendwas angezeigt werden.

> Das schon, nur die Junctions werden mit DIR nicht mehr angezeigt, das
> stimmt.

Die werden eh nur mit "dir /a" angezeigt.

>>> dir anwend*> dir.txt

>> Da kommt dann halt immer "Datei nicht gefunden".

> Bei verkürzten Verzeichnisnamen ja, nicht aber wenn er vollständig
> angegeben wird:

> j:\Users\weston\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten>dir
> anw*
> Verzeichnis von
> j:\Users\user\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten
>
> Datei nicht gefunden
>
> j:\Users\weston\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten>dir
> anwendungsdaten
>
> Verzeichnis von
> j:\Users\user\AppData\Local\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\Anwendungsdaten\anwendungsdaten
>
> 22.09.2011 08:53 <DIR> .
> 22.09.2011 08:53 <DIR> ..
> 30.06.2011 10:53 <DIR> Adobe
> 15.09.2011 09:16 <DIR> assembly
> 15.09.2011 09:16 <DIR> Microsoft
> 27.05.2011 07:40 <DIR> Microsoft Help
> 29.06.2011 16:47 <DIR> MiKTeX
> 04.08.2011 15:47 7.595 Resmon.ResmonCfg

Nö:
C:\Users\hpm\AppData\Local\Anwendungsdaten\anwendungsdaten>dir anwendungsdaten
Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten\anwendungsdaten\anwendungsdaten
Datei nicht gefunden

Es KANN nicht gehen wegen der gesetzten NTFS-Verweigerung.
Aber: "j:\Users"? Huch? Was ist das denn? "Users" ist immer auf C:
Wenn "Users" nachträglich verschoben wird, ist es eh ein vermurkstes, verbasteltes System
und man muss davon ausgehen, dass da rechtemäßig viel im Argen liegt.

>> Ich dachte jetzt, du hättest eine Möglichkeit gefunden, auf Systemen mit
>> korrekten Junctions nachvollziehbar Rekursionen zu erzeugen.
>> Das obige Spiel mit "cd anwend*" ist zwar sowas, ich kenne aber kein
>> Programm oder keinen User, der sowas machen würde.

> Dann dürften sich Dateisuchen, z.B. mit Total Commander nicht in solchen
> Pseudo-Verzeichnisbäumen festfahren.

Tut er hier ja auch nicht. Bei mir ist C:\Users allerdings auch nicht verbastelt.
Das dürfte der Unterschied sein.
Wenn ich in ...appdata\local einen Ordner "Test" erstelle und den TC in C:
suchen lasse, findet er nur "C:\Users\hpm\AppData\Local\Test"
mehr nicht. Ebenso ist es mit allen anderen Junctions auch.
Ausnahme: "All Users". Das ist allerdings keine Junction, sondern ein Symlink
und er hat keine Verweigerung von MS bekommen.
Ein Ordner "Test" wird also dummerweise zwei Mal gefunden:
Einmal in "All Users" und einmal in "Programdata".
Auch deswegen haben die Junctions die Verweigerung, sonst würden
Suchprogramme eine Flut von sinnlosen Treffern liefern.

> Anscheindend sehen die bei einem
> simplen Directory Scan mehr als DIR, sonst würden sie die rekursiven
> Unterverzeichnisse nicht finden.

Siehe oben, der TC verheddert sich da nicht, sofern das System nicht
verbastelt ist.

[...]

> Allerdings sind die Berechtigungen von "Programme" etwas anders als bei
> $Anwendungsgeraffel gesetzt:
> "Ordnerinhalt auflisten/Lesen" unter "Spezielle Berechtigungen" wird
> verweigert. Ich hatte bei $Anwendungsgeraffel die allgemein zugänglichen
> Berechtigungen "Ordnerinhalt auflisten" + "Lesen" verweigert. Worin
> besteht der Unterschied??

Da müsste man mal die Ausgabe von icacls sehen.

>>> Als ich auf dem 2008-Server in einem der betr.
>>> Verzeichnisse "DEL /S Anwendungsdaten" eingegeben habe, kam prompt die
>>> Frage, ob auch das gleichnamige Unterverzeichnis gelöscht werden soll.
>>> Ich habe an der Stelle sicherheitshalber mit "n" geantwortet.

>> Bei korrekter Junction kommt da wieder "nicht gefunden".

> Bei diesem System hat sich's durch Löschen per Commander erledigt. Beim
> nächsten probiere ich mal, ob die "speziellen" den entscheidenden
> Unterschied ausmachen.

> BTW: Wieviele Admins blicken bei den NTFS-Rechten einklich durch? Wenn
> ich das mit den schlappen 7+1 Rechten unter NetWare oder gar den 3x3
> Rechten unter Linux/Unix vergleiche ... weil es doch immer heißt,
> Windows wäre so einfach zu bedienen ...
> Die Frage, ob auch User die NTFS-Rechte beherrschen, erübrigt sich schon
> beinahe.

Jeder, der einen Rechner hat, ist ja Admin. Also kennen sich 99,9Periode%
da nicht aus. Ich bin auch weit davon entfernt, das ohne Zuhilfenahme
von Dokumentation alles im Kopf zu haben. :o)

[Christoph Maercker]

Hans-Peter Matthess wrote:
> Das ist so ähnlich wie mit den "diversen Dateimanagern". Ich hab immer
> noch keinen gefunden, der da Mist baut. Es ist z.B. der Name "TC" gefallen,
> der macht sowas hier aber nachvollziehbar nicht, sondern verhält sich korrekt.

Auf manchen Systemen hier dito.

> Gibt es ein bestimmtes Suchprogramm, mit dem sich das nachvollziehen lässt?

TC ALT-F7. Bei *Deinem* System natürlich nicht. Du wirst Dir schon die
Mühe machen müssen, mal eins der zahlreichen vermurksten(?) System zu
testen, wenn Du es unbedingt nachvollziehen willst.

> Es kann jedenfalls kein Programm eine gesetzte Verweigerung ignorieren.
> Das wäre ein glattes Wunder.

Die Rechte stehen drin, interessiert die genannten Progs nicht die Bohne.

> Die werden eh nur mit "dir /a" angezeigt.

Also auch etwas tiefer im rekursiven Verzeichnisdschungel?

> C:\Users\hpm\AppData\Local\Anwendungsdaten\anwendungsdaten>dir anwendungsdaten
> Verzeichnis von C:\Users\hpm\AppData\Local\Anwendungsdaten\anwendungsdaten\anwendungsdaten
> Datei nicht gefunden

> Es KANN nicht gehen wegen der gesetzten NTFS-Verweigerung.

Genau das ist die Frage.

> Aber: "j:\Users"? Huch? Was ist das denn? "Users" ist immer auf C:

Keine Panik: ich hatte zufällig ein Win7-System als Netzlaufwerk gemappt
und habe das als Versuchskarnickel verwendet. Lokal verhalten sich die
betr. Systeme exakt gleich.

> Tut er hier ja auch nicht. Bei mir ist C:\Users allerdings auch nicht verbastelt.
> Das dürfte der Unterschied sein.

Nein. Die Kiste, deren Netzlaufwerk ich angezapft habe, ist eines
unserer Standartimages. Und nein, nicht nur die haben den Fehler,
sondern auch Systeme, die von völlig anderen Firmen/Leuten installiert
wurden. Hierzugroups scheint es etliche weitere zu geben.

> Wenn ich in ...appdata\local einen Ordner "Test" erstelle und den TC in C:
> suchen lasse, findet er nur "C:\Users\hpm\AppData\Local\Test"
> mehr nicht. Ebenso ist es mit allen anderen Junctions auch.

Ein einziges Mal habe ich das bei einem vorher vermurksten System so
hinbekommen, auf meinem Home-PC und ich hoffe, es bleibt dort so. ALT-F7
ist für mich die schnellste Prüfmethode, ob der Mist komplett weg ist.

>> Allerdings sind die Berechtigungen von "Programme" etwas anders als bei
>> $Anwendungsgeraffel gesetzt:
>> "Ordnerinhalt auflisten/Lesen" unter "Spezielle Berechtigungen" wird
>> verweigert. Ich hatte bei $Anwendungsgeraffel die allgemein zugänglichen
>> Berechtigungen "Ordnerinhalt auflisten" + "Lesen" verweigert. Worin
>> besteht der Unterschied??
>
> Da müsste man mal die Ausgabe von icacls sehen.

OK:
C:\>icacls \users\user\* /T
C:\users\user\Anwendungsdaten Jeder:(DENY)(S,RD)
NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)

C:\users\user\Anwendungsdaten\*: Zugriff verweigert

C:\>icacls \users\user\AppData\Local\* /T
C:\users\user\AppData NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)

C:\users\user\Application Data NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)

C:\users\user\AppData\Local\Anwendungsdaten Jeder:(DENY)(S,RD)
NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)

VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
IMED\user:(I)(OI)(CI)(F)

C:\users\user\AppData\Local\Anwendungsdaten\*: Zugriff verweigert>

Preisfrage: Treten bei diesem System Rekursionen auf oder nicht?
--


CU Christoph Maercker.

[Hans-Peter Matthess]

Christoph Maercker:

>> Gibt es ein bestimmtes Suchprogramm, mit dem sich das nachvollziehen lässt?

> TC ALT-F7. Bei *Deinem* System natürlich nicht. Du wirst Dir schon die
> Mühe machen müssen, mal eins der zahlreichen vermurksten(?) System zu
> testen, wenn Du es unbedingt nachvollziehen willst.

Wozu? Dass es mit vermurksten Junctions Probleme gibt, ist ja eh klar.
Ich kann solche Rekursionen leicht erzeugen, wenn ich die Rechte verändere.
Mit geht's nur um Probleme mit korrekt funktionierenden Junctions.
Also sowas z.B.:
http://blog.magerquark.de/request-for-help-robocopy-dummfug-unter-windows-vista/
http://www.borncity.com/blog/2009/12/14/pfadlangenlimit-uberschritten-dateisystemobjekte-scheinbar-nicht-mehr-loschbar/

>> Es KANN nicht gehen wegen der gesetzten NTFS-Verweigerung.

> Genau das ist die Frage.

Nö, das ist keine Frage. Kein Programm kann Rechte übergehen. Wenn das
scheinbar doch der Fall ist, hat man beim Setzen der Rechte etwas übersehen
und falsch gemacht.

>> Aber: "j:\Users"? Huch? Was ist das denn? "Users" ist immer auf C:

> Keine Panik: ich hatte zufällig ein Win7-System als Netzlaufwerk gemappt
> und habe das als Versuchskarnickel verwendet. Lokal verhalten sich die
> betr. Systeme exakt gleich.

So kann man eh nicht richtig testen. Die Junction, die eigentlich auf einen
Pfad im anderen System zeigt, zeigt dann ja nun auf das lokale System...

>>> Allerdings sind die Berechtigungen von "Programme" etwas anders als bei
>>> $Anwendungsgeraffel gesetzt:
>>> "Ordnerinhalt auflisten/Lesen" unter "Spezielle Berechtigungen" wird
>>> verweigert. Ich hatte bei $Anwendungsgeraffel die allgemein zugänglichen
>>> Berechtigungen "Ordnerinhalt auflisten" + "Lesen" verweigert. Worin
>>> besteht der Unterschied??

>> Da müsste man mal die Ausgabe von icacls sehen.

> OK:
> C:\>icacls \users\user\* /T
> C:\users\user\Anwendungsdaten Jeder:(DENY)(S,RD)
> NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
> VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
> IMED\user:(I)(OI)(CI)(F)

Sieht gut aus.

> C:\users\user\Anwendungsdaten\*: Zugriff verweigert

Kapott. Evtl. mal icacls in einer Konsole ausführen, die Systemrechte hat.

> C:\users\user\Application Data NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
> VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
> IMED\user:(I)(OI)(CI)(F)

Kapott. Die Verweigerung fehlt.

> C:\users\user\AppData\Local\Anwendungsdaten Jeder:(DENY)(S,RD)
> NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
> VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
> IMED\user:(I)(OI)(CI)(F)

Das sieht wieder gut aus.

> C:\users\user\AppData\Local\Anwendungsdaten\*: Zugriff verweigert>

Ziemlich vermurkst.

> Preisfrage: Treten bei diesem System Rekursionen auf oder nicht?

Bei solch einem vermurksten Bild würde ich alle Junctions löschen.
Jetzt wüsste ich nur noch gerne, wie man sowas zustande bringt. ;-)

[Christoph Maercker]

Hans-Peter Matthess wrote:
> Nö, das ist keine Frage. Kein Programm kann Rechte übergehen. Wenn das
> scheinbar doch der Fall ist, hat man beim Setzen der Rechte etwas übersehen
> und falsch gemacht.

> So kann man eh nicht richtig testen. Die Junction, die eigentlich auf einen
> Pfad im anderen System zeigt, zeigt dann ja nun auf das lokale System...

Lokal funktioniert's aber exakt genauso.

>> C:\>icacls \users\user\* /T
>> C:\users\user\Anwendungsdaten Jeder:(DENY)(S,RD)
>> NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
>> VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
>> IMED\user:(I)(OI)(CI)(F)
>
> Sieht gut aus.
>
>> C:\users\user\Anwendungsdaten\*: Zugriff verweigert
>
> Kapott. Evtl. mal icacls in einer Konsole ausführen, die Systemrechte hat.
>
>> C:\users\user\Application Data NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
>> VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
>> IMED\user:(I)(OI)(CI)(F)

> Kapott. Die Verweigerung fehlt.

Hat aber mit den Rekursionen nichts zu tun, da Parallelverzeichnis.

>> C:\users\user\AppData\Local\Anwendungsdaten Jeder:(DENY)(S,RD)
>> NT-AUTORITŽT\SYSTEM:(I)(OI)(CI)(F)
>> VORDEFINIERT\Administratoren:(I)(OI)(CI)(F)
>> IMED\user:(I)(OI)(CI)(F)
>
> Das sieht wieder gut aus.
>
>> C:\users\user\AppData\Local\Anwendungsdaten\*: Zugriff verweigert>
>
> Ziemlich vermurkst.
>
>> Preisfrage: Treten bei diesem System Rekursionen auf oder nicht?

Antwort: Es gibt welche, obwohl die Rechte auf "Anwendungsdaten" korrekt
gesetzt sind.

> Bei solch einem vermurksten Bild würde ich alle Junctions löschen.

Bei einigen Systemen bereits passiert.

> Jetzt wüsste ich nur noch gerne, wie man sowas zustande bringt. ;-)

*Diese* Frage sollte M$ beantworten, wenn hierzugroups schon niemand die
Antwort kennt. Nachdem ich das Problem auf drei grundverschiedenen
Windows-Systemen gesehen habe, fällt der Verdacht sowieso auf dero
Wind...Installer.

--


CU Christoph Maercker.

[Helmut Rohrbeck]

Christoph Maercker typed:

>> Jetzt wüsste ich nur noch gerne, wie man sowas zustande bringt. ;-)
>
> *Diese* Frage sollte M$ beantworten, wenn hierzugroups schon niemand
> die Antwort kennt. Nachdem ich das Problem auf drei grundverschiedenen
> Windows-Systemen gesehen habe, fällt der Verdacht sowieso auf dero
> Wind...Installer.

Dann solltest Du einfach mal bei "M$" fragen:
http://answers.microsoft.com/de-de/windows/forum/windows_7

--
Helmut Rohrbeck
http://www.helmrohr.de/Kontakt.htm
Microsoft Support Center:
http://support.microsoft.com/?ln=de

[Christoph Maercker]

Helmut Rohrbeck wrote:
> Dann solltest Du einfach mal bei "M$" fragen:
> http://answers.microsoft.com/de-de/windows/forum/windows_7

Danke, ich bin in MS-Foren eher nicht "zu Hause, deshalb frage ich dort
zunächst, ob schon danach gefragt wurde. ;-) Angesichts der vielen User,
die offenbar das gleiche Problem haben, wurde die Frage wahrscheinlich
längst gestellt.
Auf meinem Home-PC sind die Rekursionen übrigens weg, nachdem ich die
Rechte verweigert habe und zwar nicht "spezielle", sondern einfach
"Ordnerinhalt auflisten" und Lesen. Bei dem W2008-Server, wegen dem ich
den Thread aufgemacht habe, hat hingegen nur Löschen der Junctions
geholfen. Warum, weiß der Geier.
--


CU Christoph Maercker.

[Hans-Peter Matthess]

Christoph Maercker:

>> Jetzt wüsste ich nur noch gerne, wie man sowas zustande bringt. ;-)

> *Diese* Frage sollte M$ beantworten, wenn hierzugroups schon niemand die
> Antwort kennt. Nachdem ich das Problem auf drei grundverschiedenen
> Windows-Systemen gesehen habe, fällt der Verdacht sowieso auf dero
> Wind...Installer.

Nö, bei einem sauber installierten System gibt's keine Rekursionen
und auch der Windows-Installer erzeugt keine. Insofern kann MS da
nichts beantworten.