Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Ist mklink bei Windows 7 64bit problematisch?
493 views
Skip to first unread message
Heinz Wolf
Dec 11, 2011, 6:09:12 AM12/11/11
to
Hi,
in der Taskleiste habe ich ein paar "Neue Smbolleiste..." eingelinkt, die
von mir entsprechend angelegte Ordner und Dateien
enthalten, dort auch im windows dateiexplorer angelegte links, die auf
files und Ordner verweisen. So weit so gut.
Nun will man ja auch dort nicht nur links auf Ordner, sondern auch
Referenzen auf Ordner haben, womit man als Administrator per z.B.
mklink /d c:\aref f:\b
(beliebige Namen und Pfade) alles samt Unterordnern und alle files unter
dem link c:\aref von der taskleiste her einfach durch das Drüberfahren mit
der Maus auf- und wieder zublenden kann, was in Wirklichkeit unter f:\b
liegt. Im Dateiexplorer wird dann c:\aref unter c:\ als link mit dem Namen
aref auf den Ordner f:\b angezeigt.
Das funktioniert voll. Damit kann man also beliebig verästelte
Festplatten-Pfade zusammenfassen und von der Tasleiste her rasch dynamisch
durchnavigieren.
Und nun die Frage bitte:
kann es sein, dass man versehentlich f:\b und alles darunter löschen kann,
wenn man c:\aref löscht?
Mir scheint das unlängst passiert zu sein, wobei ich es aber nicht
reproduzieren kann.
Seither gebe ich das Wichtigste täglich auf den USB-stick raus.
Woran kann es also bitte gelegen haben, daß es weg war?
Vielen Dank
HW
in der Taskleiste habe ich ein paar "Neue Smbolleiste..." eingelinkt, die
von mir entsprechend angelegte Ordner und Dateien
enthalten, dort auch im windows dateiexplorer angelegte links, die auf
files und Ordner verweisen. So weit so gut.
Nun will man ja auch dort nicht nur links auf Ordner, sondern auch
Referenzen auf Ordner haben, womit man als Administrator per z.B.
mklink /d c:\aref f:\b
(beliebige Namen und Pfade) alles samt Unterordnern und alle files unter
dem link c:\aref von der taskleiste her einfach durch das Drüberfahren mit
der Maus auf- und wieder zublenden kann, was in Wirklichkeit unter f:\b
liegt. Im Dateiexplorer wird dann c:\aref unter c:\ als link mit dem Namen
aref auf den Ordner f:\b angezeigt.
Das funktioniert voll. Damit kann man also beliebig verästelte
Festplatten-Pfade zusammenfassen und von der Tasleiste her rasch dynamisch
durchnavigieren.
Und nun die Frage bitte:
kann es sein, dass man versehentlich f:\b und alles darunter löschen kann,
wenn man c:\aref löscht?
Mir scheint das unlängst passiert zu sein, wobei ich es aber nicht
reproduzieren kann.
Seither gebe ich das Wichtigste täglich auf den USB-stick raus.
Woran kann es also bitte gelegen haben, daß es weg war?
Vielen Dank
HW
Heinz Chrudina
Dec 11, 2011, 7:17:01 AM12/11/11
to
Am 11.Dez.2011 12:09, schrieb Heinz Wolf:
> Hi,
> in der Taskleiste habe ich ein paar "Neue Smbolleiste..." eingelinkt, die
> von mir entsprechend angelegte Ordner und Dateien
> enthalten, dort auch im windows dateiexplorer angelegte links, die auf
> files und Ordner verweisen. So weit so gut.
> Hi,
> in der Taskleiste habe ich ein paar "Neue Smbolleiste..." eingelinkt, die
> von mir entsprechend angelegte Ordner und Dateien
> enthalten, dort auch im windows dateiexplorer angelegte links, die auf
> files und Ordner verweisen. So weit so gut.
> Und nun die Frage bitte:
> kann es sein, dass man versehentlich f:\b und alles darunter löschen kann,
> wenn man c:\aref löscht?
>
> Mir scheint das unlängst passiert zu sein, wobei ich es aber nicht
> reproduzieren kann.
Mir fallen dazu nur die Bibliotheken ein, aber das passt auch nicht so
> kann es sein, dass man versehentlich f:\b und alles darunter löschen kann,
> wenn man c:\aref löscht?
>
> Mir scheint das unlängst passiert zu sein, wobei ich es aber nicht
> reproduzieren kann.
ganz zu Deiner Beschreibung:
http://windows.microsoft.com/de-DE/windows7/Libraries-frequently-asked-questions
Was passiert beim Löschen einer Bibliothek oder der Elemente in einer
Bibliothek?
Heinz
--
Verantwortlich ist man nicht nur für das, was man tut,
sondern auch für das, was man nicht tut. (Lao-Tse)
Heinz Wolf
Dec 11, 2011, 7:39:40 AM12/11/11
to
Heinz Chrudina <H.Chr...@gmx.de>:
...
Ok, habe mal Bibliotheken->Bilder im Windowsexplorer glöscht.
Im Papierkorp liegt "Pictures" 4kb.
Die Dateien sind aber nicht gelöscht.
"Standartbibliotheken wiederherstellen" bringt diese Bibiliothek wieder,
ohne daß was weg ist. Das dann nochmal mit demselben Resultat.
HW
...
> Mir fallen dazu nur die Bibliotheken ein, aber das passt auch nicht so
> ganz zu Deiner Beschreibung:
>
> http://windows.microsoft.com/de-DE/windows7/Libraries-frequently-asked-qu
> estions
>
> Was passiert beim Löschen einer Bibliothek oder der Elemente in einer
> Bibliothek?
>
> Heinz
Mit Bibliotheken kenne ich mich nicht aus, habe damit nie was gemacht.
> ganz zu Deiner Beschreibung:
>
> http://windows.microsoft.com/de-DE/windows7/Libraries-frequently-asked-qu
> estions
>
> Was passiert beim Löschen einer Bibliothek oder der Elemente in einer
> Bibliothek?
>
> Heinz
Ok, habe mal Bibliotheken->Bilder im Windowsexplorer glöscht.
Im Papierkorp liegt "Pictures" 4kb.
Die Dateien sind aber nicht gelöscht.
"Standartbibliotheken wiederherstellen" bringt diese Bibiliothek wieder,
ohne daß was weg ist. Das dann nochmal mit demselben Resultat.
HW
Heinz Wolf
Dec 11, 2011, 8:27:33 AM12/11/11
to
Das ist ja lustig:
sind Bibliotheken wohl mlinks?
Wenn ich Bibliotheken anlege und sie in die unter "Neue Symbolleiste..."
zugänglich gemachte Ordnerstrukturen reinkopiere, blenden sie dort alles
darunter auf. Wenn ich diese reinkopierte Bilibothek dort an diesem neuen
Ort lösche, ist im Papierkorb ein Ordner mit dem Namen der Bibliothek und
mit der Größe des Originalordnerinhalts. Das war kein link, sondern
offenbar wurde alles dorthin kopiert. Der Originalordner wird aber nicht
gelöscht. Auch dann nicht, wenn ich den Papierkorb leere. Dasselbe, wenn
ich einen link auf die Bibliothek anlege. Lösche in den link, ist sonst
alles unverändert- Wobei die im Dateiexporer angelegte Bibliothek bleibt
und nur 2kb groß ist, wenn sie im Papierkorb liegt. Lösche ich sie, ist
der Originalordner ebenso immer noch da.
Sehr seltsam alles, aber immerhin bleibt der Originalordner samt files und
Unterordnern voll erhalten.
Wüßte nur gern, ob da was schiefgelaufen sein kann.
Wenn man das dann weiß, kann mans verhindern.
Bisher ist mir das etwas unsicher, weswegen ich mit mlink Angelegtes
lieber täglich sichere.
Auf jeden Fall blendet nur mlink alle damit unter "Neue Symbolleiste..."
angelegten links auf Ordner in ihren Unterverzweigungen mit darüber
gleitender Maus dynamisch auf und zu. Damit erhält man den vollen
dynamischen Überblick über aktuelle Ordnerinhalte, ohne irgendwas
anklicken zu müssen - man muß nur einmal auf das entsprechende ">>" in der
Taskleiste klicken.
sind Bibliotheken wohl mlinks?
Wenn ich Bibliotheken anlege und sie in die unter "Neue Symbolleiste..."
zugänglich gemachte Ordnerstrukturen reinkopiere, blenden sie dort alles
darunter auf. Wenn ich diese reinkopierte Bilibothek dort an diesem neuen
Ort lösche, ist im Papierkorb ein Ordner mit dem Namen der Bibliothek und
mit der Größe des Originalordnerinhalts. Das war kein link, sondern
offenbar wurde alles dorthin kopiert. Der Originalordner wird aber nicht
gelöscht. Auch dann nicht, wenn ich den Papierkorb leere. Dasselbe, wenn
ich einen link auf die Bibliothek anlege. Lösche in den link, ist sonst
alles unverändert- Wobei die im Dateiexporer angelegte Bibliothek bleibt
und nur 2kb groß ist, wenn sie im Papierkorb liegt. Lösche ich sie, ist
der Originalordner ebenso immer noch da.
Sehr seltsam alles, aber immerhin bleibt der Originalordner samt files und
Unterordnern voll erhalten.
Wüßte nur gern, ob da was schiefgelaufen sein kann.
Wenn man das dann weiß, kann mans verhindern.
Bisher ist mir das etwas unsicher, weswegen ich mit mlink Angelegtes
lieber täglich sichere.
Auf jeden Fall blendet nur mlink alle damit unter "Neue Symbolleiste..."
angelegten links auf Ordner in ihren Unterverzweigungen mit darüber
gleitender Maus dynamisch auf und zu. Damit erhält man den vollen
dynamischen Überblick über aktuelle Ordnerinhalte, ohne irgendwas
anklicken zu müssen - man muß nur einmal auf das entsprechende ">>" in der
Taskleiste klicken.
Heinz Wolf
Dec 11, 2011, 8:31:33 AM12/11/11
to
Falls es interessiert:
Es war wohl mein Fehler.
Neben dem völlig eigenständig gewählten Namen des mklink-"Ordners" tauchte
im vorliegenden Fall beim Drüberfahren mit der Maus gleich der oberste
Ordner der damit dynamisiert zugänglich gemachten dortigen lokalen
Unterordner- und FileStruktur auf.
Da kann es nun passiert sein, daß ich nicht den mklink-"Ordner", sondern
diesen obersten Ordner und damit tatsächlich alles dort darunter
Befindliche gelöscht habe. Der mklink-"Ordner" steht dann weiterhin dort,
blendet nur nichts mehr darunter auf, weils in dem Fall eben von mir
gelöscht wurde. Dann habe ich diesen mklink-"Ordner" gelöscht und mir
eingebildet, damit real auf der Festplatte was gelöscht zu haben, was aber
gar nicht stimmt, weils schon weg war, weil das damit zudem gottseidank
gar nicht geht.
Dumm gelaufen - eine gemeine Falle, die ich mir da gestellt habe.
Also Vorsicht beim Löschen von mklink-"Ordnern":
Nicht aus Versehen einen daneben aufblendenden Einstiegsordner löschen.
Denn dann ist dort alles weg.
mklink-"Ordner" kann man bedenkenlos löschen: das verändert auf der
Festplatte gar nix. Das gilt auch für Bibliotheken, die mir aber gegenüber
mklink-Symbolleisten viel zu unhandlich sind.
Dann noch:
natürlich kann man unter diesen ">>" auf der Taskleiste ganz ohne mklink
auch z.B. Partitions zuordnen und die dann ohne weiteres Klicken dynamisch
mit der Maus durchforsten. Das ist allerdings höchst unübersichtlich.
Daher gebe ich eben mehrere mklinks mit aussagekräftigen Namen in einen
"SymbolleistenOrdner", um dort sofort gezielt dynamischen Zugriff zu
haben. Das ist besser, als Bibliotheken einzurichten. Man kommt viel
schneller ran. Aber eben Vorsicht beim Löschen von mlinks, nicht
stattdessen daneben aufblendende reale Ordner versehentlich löschen.
Das wars dann wohl.
Es war wohl mein Fehler.
Neben dem völlig eigenständig gewählten Namen des mklink-"Ordners" tauchte
im vorliegenden Fall beim Drüberfahren mit der Maus gleich der oberste
Ordner der damit dynamisiert zugänglich gemachten dortigen lokalen
Unterordner- und FileStruktur auf.
Da kann es nun passiert sein, daß ich nicht den mklink-"Ordner", sondern
diesen obersten Ordner und damit tatsächlich alles dort darunter
Befindliche gelöscht habe. Der mklink-"Ordner" steht dann weiterhin dort,
blendet nur nichts mehr darunter auf, weils in dem Fall eben von mir
gelöscht wurde. Dann habe ich diesen mklink-"Ordner" gelöscht und mir
eingebildet, damit real auf der Festplatte was gelöscht zu haben, was aber
gar nicht stimmt, weils schon weg war, weil das damit zudem gottseidank
gar nicht geht.
Dumm gelaufen - eine gemeine Falle, die ich mir da gestellt habe.
Also Vorsicht beim Löschen von mklink-"Ordnern":
Nicht aus Versehen einen daneben aufblendenden Einstiegsordner löschen.
Denn dann ist dort alles weg.
mklink-"Ordner" kann man bedenkenlos löschen: das verändert auf der
Festplatte gar nix. Das gilt auch für Bibliotheken, die mir aber gegenüber
mklink-Symbolleisten viel zu unhandlich sind.
Dann noch:
natürlich kann man unter diesen ">>" auf der Taskleiste ganz ohne mklink
auch z.B. Partitions zuordnen und die dann ohne weiteres Klicken dynamisch
mit der Maus durchforsten. Das ist allerdings höchst unübersichtlich.
Daher gebe ich eben mehrere mklinks mit aussagekräftigen Namen in einen
"SymbolleistenOrdner", um dort sofort gezielt dynamischen Zugriff zu
haben. Das ist besser, als Bibliotheken einzurichten. Man kommt viel
schneller ran. Aber eben Vorsicht beim Löschen von mlinks, nicht
stattdessen daneben aufblendende reale Ordner versehentlich löschen.
Das wars dann wohl.
Rainald Taesler
Dec 11, 2011, 9:42:24 AM12/11/11
to
Heinz Wolf wrote:
[...]
"Kommandozeile" (cmd) vorsichtig sein, wenn man "zu Fuß" unterwegs ist.
Mit "DEL" ("del aref" [name des Links]) löscht man automatisch alles,
was an Dateien im referenzierten Ordner liegt. Lediglich
Unterverzeichnisse bleiben verschont.
Rainald
[...]
> Und nun die Frage bitte:
> kann es sein, dass man versehentlich f:\b und alles darunter löschen
> kann, wenn man c:\aref löscht?
>
> Mir scheint das unlängst passiert zu sein, wobei ich es aber nicht
> reproduzieren kann.
>
> Seither gebe ich das Wichtigste täglich auf den USB-stick raus.
>
> Woran kann es also bitte gelegen haben, daß es weg war?
Neben dem, was Du inzwischen berichtet hast, muß man auch in einer
> kann es sein, dass man versehentlich f:\b und alles darunter löschen
> kann, wenn man c:\aref löscht?
>
> Mir scheint das unlängst passiert zu sein, wobei ich es aber nicht
> reproduzieren kann.
>
> Seither gebe ich das Wichtigste täglich auf den USB-stick raus.
>
> Woran kann es also bitte gelegen haben, daß es weg war?
"Kommandozeile" (cmd) vorsichtig sein, wenn man "zu Fuß" unterwegs ist.
Mit "DEL" ("del aref" [name des Links]) löscht man automatisch alles,
was an Dateien im referenzierten Ordner liegt. Lediglich
Unterverzeichnisse bleiben verschont.
Rainald
Heinz Wolf
Dec 11, 2011, 10:14:06 AM12/11/11
to
"Rainald Taesler" <tae...@gmx.de>:
...
Gehe ich mit der Maus über einen in einer Symbolleiste aufgeblendeten
mklink-"Ordner", klicke ich dort rechts auf ihn, wird dort wie üblich u.a.
"löschen" angeboten. Lösche ich diesen Ordner, sind die damit
referenzierten Original(Unter)Ordner samt files nicht weg, sie bleiben,
nur dieser willkürlich gewählte mklink-Ordnername ist weg.
mklink bedingt, cmd als Administrator auszuführen.
HW
...
> Neben dem, was Du inzwischen berichtet hast, muß man auch in einer
> "Kommandozeile" (cmd) vorsichtig sein, wenn man "zu Fuß" unterwegs ist.
> Mit "DEL" ("del aref" [name des Links]) löscht man automatisch alles,
> was an Dateien im referenzierten Ordner liegt. Lediglich
> Unterverzeichnisse bleiben verschont.
>
> Rainald
>
>
Oh, gut zu wissen.
> "Kommandozeile" (cmd) vorsichtig sein, wenn man "zu Fuß" unterwegs ist.
> Mit "DEL" ("del aref" [name des Links]) löscht man automatisch alles,
> was an Dateien im referenzierten Ordner liegt. Lediglich
> Unterverzeichnisse bleiben verschont.
>
> Rainald
>
>
Gehe ich mit der Maus über einen in einer Symbolleiste aufgeblendeten
mklink-"Ordner", klicke ich dort rechts auf ihn, wird dort wie üblich u.a.
"löschen" angeboten. Lösche ich diesen Ordner, sind die damit
referenzierten Original(Unter)Ordner samt files nicht weg, sie bleiben,
nur dieser willkürlich gewählte mklink-Ordnername ist weg.
mklink bedingt, cmd als Administrator auszuführen.
HW
Hans-Peter Matthess
Dec 11, 2011, 2:39:02 PM12/11/11
to
Heinz Wolf:
> mklink bedingt, cmd als Administrator auszuführen.
Nein, mklink braucht keine erhöhten Rechte.
--
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
> mklink bedingt, cmd als Administrator auszuführen.
--
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
Heinz Wolf
Dec 11, 2011, 4:55:46 PM12/11/11
to
Hans-Peter Matthess <hp...@t-online.de>:
> Heinz Wolf:
>
>> mklink bedingt, cmd als Administrator auszuführen.
>
> Nein, mklink braucht keine erhöhten Rechte.
>
Dann steht bei mir (Windows 7 Home Premium 64bit) in cmd:
"Ihre Berechtigungen reichen nicht aus, um diesen Vorgang auszuführen."
> Heinz Wolf:
>
>> mklink bedingt, cmd als Administrator auszuführen.
>
> Nein, mklink braucht keine erhöhten Rechte.
>
"Ihre Berechtigungen reichen nicht aus, um diesen Vorgang auszuführen."
Hans-Peter Matthess
Dec 11, 2011, 5:50:07 PM12/11/11
to
Heinz Wolf:
>> Nein, mklink braucht keine erhöhten Rechte.
> Dann steht bei mir (Windows 7 Home Premium 64bit) in cmd:
> "Ihre Berechtigungen reichen nicht aus, um diesen Vorgang auszuführen."
Das liegt aber nicht an mklink, sondern an den Rechten von
Quell/Zielverzeichnis. Wenn ich in einem Verzeichnis keine passenden Rechte
habe, kann ich dort auch keine NTFS-Links erzeugen. Grundsätzlich
funktioniert mklink mit eingeschränkten Userrechten.
>> Nein, mklink braucht keine erhöhten Rechte.
> Dann steht bei mir (Windows 7 Home Premium 64bit) in cmd:
> "Ihre Berechtigungen reichen nicht aus, um diesen Vorgang auszuführen."
Quell/Zielverzeichnis. Wenn ich in einem Verzeichnis keine passenden Rechte
habe, kann ich dort auch keine NTFS-Links erzeugen. Grundsätzlich
funktioniert mklink mit eingeschränkten Userrechten.
Heinz Wolf
Dec 11, 2011, 6:38:12 PM12/11/11
to
Hans-Peter Matthess <hp...@t-online.de>:
> Heinz Wolf:
>
>>> Nein, mklink braucht keine erhöhten Rechte.
>
>> Dann steht bei mir (Windows 7 Home Premium 64bit) in cmd:
>> "Ihre Berechtigungen reichen nicht aus, um diesen Vorgang auszuführen."
>
> Das liegt aber nicht an mklink, sondern an den Rechten von
> Quell/Zielverzeichnis. Wenn ich in einem Verzeichnis keine passenden
> Rechte habe, kann ich dort auch keine NTFS-Links erzeugen. Grundsätzlich
> funktioniert mklink mit eingeschränkten Userrechten.
>
mklink kann ich offenbar nur mit cmd.exe aufrufen.
Alle Versuche scheiterten, es ohne cmd.exe "als Administrator ausführen"
zu schaffen. Kann an mir liegen - viell. habe ich nicht alles versucht.
Andere DOS-Befehle funktionieren ohne diesen Administratorstatus, offenbar
nur mklink nicht.
> Heinz Wolf:
>
>>> Nein, mklink braucht keine erhöhten Rechte.
>
>> Dann steht bei mir (Windows 7 Home Premium 64bit) in cmd:
>> "Ihre Berechtigungen reichen nicht aus, um diesen Vorgang auszuführen."
>
> Das liegt aber nicht an mklink, sondern an den Rechten von
> Quell/Zielverzeichnis. Wenn ich in einem Verzeichnis keine passenden
> Rechte habe, kann ich dort auch keine NTFS-Links erzeugen. Grundsätzlich
> funktioniert mklink mit eingeschränkten Userrechten.
>
Alle Versuche scheiterten, es ohne cmd.exe "als Administrator ausführen"
zu schaffen. Kann an mir liegen - viell. habe ich nicht alles versucht.
Andere DOS-Befehle funktionieren ohne diesen Administratorstatus, offenbar
nur mklink nicht.
Hans-Peter Matthess
Dec 12, 2011, 6:50:55 AM12/12/11
to
Heinz Wolf:
>>>> Nein, mklink braucht keine erhöhten Rechte.
>>> Dann steht bei mir (Windows 7 Home Premium 64bit) in cmd:
>>> "Ihre Berechtigungen reichen nicht aus, um diesen Vorgang auszuführen."
>> Das liegt aber nicht an mklink, sondern an den Rechten von
>> Quell/Zielverzeichnis. Wenn ich in einem Verzeichnis keine passenden
>> Rechte habe, kann ich dort auch keine NTFS-Links erzeugen. Grundsätzlich
>> funktioniert mklink mit eingeschränkten Userrechten.
> mklink kann ich offenbar nur mit cmd.exe aufrufen.
> Alle Versuche scheiterten, es ohne cmd.exe "als Administrator ausführen"
> zu schaffen. Kann an mir liegen - viell. habe ich nicht alles versucht.
Man kann mklink auch in eine Batchdatei packen, dann geht es auch ohne
>>>> Nein, mklink braucht keine erhöhten Rechte.
>>> Dann steht bei mir (Windows 7 Home Premium 64bit) in cmd:
>>> "Ihre Berechtigungen reichen nicht aus, um diesen Vorgang auszuführen."
>> Das liegt aber nicht an mklink, sondern an den Rechten von
>> Quell/Zielverzeichnis. Wenn ich in einem Verzeichnis keine passenden
>> Rechte habe, kann ich dort auch keine NTFS-Links erzeugen. Grundsätzlich
>> funktioniert mklink mit eingeschränkten Userrechten.
> mklink kann ich offenbar nur mit cmd.exe aufrufen.
> Alle Versuche scheiterten, es ohne cmd.exe "als Administrator ausführen"
> zu schaffen. Kann an mir liegen - viell. habe ich nicht alles versucht.
Aufruf von cmd.exe. Wenn ein Verzeichnis aber zum Beschreiben erhöhte
Rechte verlangt, muss man die Batchdatei eben mit erhöhten Rechten
ausführen, wenn nicht, dann genügen normale Rechte.
Noch mal: mklink selbst braucht keine erhöhten Rechte. Es wäre auch
albern, wenn man zum Erstellen eines lausigen Ordners oder eines Links
erhöhte Rechte brauchte.
> Andere DOS-Befehle funktionieren ohne diesen Administratorstatus, offenbar
> nur mklink nicht.
das erhöhte Rechte benötigt, braucht man dafür natürlich auch Adminrechte.
Rainald Taesler
Dec 11, 2011, 11:34:20 AM12/11/11
to
Heinz Wolf wrote:
> "Rainald Taesler" <tae...@gmx.de>:
> ...
>> Neben dem, was Du inzwischen berichtet hast, muß man auch in einer
>> "Kommandozeile" (cmd) vorsichtig sein, wenn man "zu Fuß" unterwegs
>> ist. Mit "DEL" ("del aref" [name des Links]) löscht man automatisch
>> alles, was an Dateien im referenzierten Ordner liegt. Lediglich
>> Unterverzeichnisse bleiben verschont.
>
> "Rainald Taesler" <tae...@gmx.de>:
> ...
>> Neben dem, was Du inzwischen berichtet hast, muß man auch in einer
>> "Kommandozeile" (cmd) vorsichtig sein, wenn man "zu Fuß" unterwegs
>> ist. Mit "DEL" ("del aref" [name des Links]) löscht man automatisch
>> alles, was an Dateien im referenzierten Ordner liegt. Lediglich
>> Unterverzeichnisse bleiben verschont.
>
> Oh, gut zu wissen.
> Gehe ich mit der Maus über einen in einer Symbolleiste aufgeblendeten
> mklink-"Ordner", klicke ich dort rechts auf ihn, wird dort wie üblich
> u.a. "löschen" angeboten. Lösche ich diesen Ordner, sind die damit
> referenzierten Original(Unter)Ordner samt files nicht weg, sie
> bleiben, nur dieser willkürlich gewählte mklink-Ordnername ist weg.
Ja.
> Gehe ich mit der Maus über einen in einer Symbolleiste aufgeblendeten
> mklink-"Ordner", klicke ich dort rechts auf ihn, wird dort wie üblich
> u.a. "löschen" angeboten. Lösche ich diesen Ordner, sind die damit
> referenzierten Original(Unter)Ordner samt files nicht weg, sie
> bleiben, nur dieser willkürlich gewählte mklink-Ordnername ist weg.
Das entspricht dem CMD-Kommando "RMDIR". Der symbolische Link wird
beseitigt, das referenzierte Verzeichnis bleibt.
> mklink bedingt, cmd als Administrator auszuführen.
Rainald
Rainald Taesler
Dec 12, 2011, 11:23:09 AM12/12/11
to
Hans-Peter Matthess wrote:
> Heinz Wolf:
>>> Nein, mklink braucht keine erhöhten Rechte.
>
>> Dann steht bei mir (Windows 7 Home Premium 64bit) in cmd:
>> "Ihre Berechtigungen reichen nicht aus, um diesen Vorgang
>> auszuführen."
>
> Das liegt aber nicht an mklink, sondern an den Rechten von
> Quell/Zielverzeichnis.
Nein, es liegt an MKLINK.
> Heinz Wolf:
>>> Nein, mklink braucht keine erhöhten Rechte.
>
>> Dann steht bei mir (Windows 7 Home Premium 64bit) in cmd:
>> "Ihre Berechtigungen reichen nicht aus, um diesen Vorgang
>> auszuführen."
>
> Das liegt aber nicht an mklink, sondern an den Rechten von
> Quell/Zielverzeichnis.
> Wenn ich in einem Verzeichnis keine passenden
> Rechte habe, kann ich dort auch keine NTFS-Links erzeugen.
> Grundsätzlich funktioniert mklink mit eingeschränkten Userrechten.
nochmal probiert, sowohl unter Win7, als auch unter Vista.
Wenn CMD nicht mit Administratorrechte ausgeführt wird, erscheint die
vom OP oben zitierte Fehlermeldung.
Dies bei einem Verzeichnis, auf das ich "vollen Zugriff" habe und mit
einem ebensolchen Ziel-Verzeichnis[1].
Wird CMD "Als Administartor ausführen" aufgerufen, klappt es
selbstverständlich.
Rainald
[1] C:\users\tmp\> mklink /d test e:\tmp
Hans-Peter Matthess
Dec 12, 2011, 12:16:29 PM12/12/11
to
Rainald Taesler:
> Nein, es liegt an MKLINK.
Ich hab's gerade noch mal getestet. Wir haben beide Recht:
Es liegt am Parameter: Mit dem Parameter /J braucht's keine erhöhten Rechte,
mit /D hingegen schon. Sachen gibt's....
Da ich hier nur mit Junctions, nicht mit Symlinks arbeite, war mir das nie
aufgefallen.
> Nein, es liegt an MKLINK.
Es liegt am Parameter: Mit dem Parameter /J braucht's keine erhöhten Rechte,
mit /D hingegen schon. Sachen gibt's....
Da ich hier nur mit Junctions, nicht mit Symlinks arbeite, war mir das nie
aufgefallen.
Rainald Taesler
Dec 12, 2011, 1:22:15 PM12/12/11
to
Hans-Peter Matthess wrote:
> Rainald Taesler:
>
>> Nein, es liegt an MKLINK.
>
> Ich hab's gerade noch mal getestet. Wir haben beide Recht:
> Es liegt am Parameter: Mit dem Parameter /J braucht's keine erhöhten
> Rechte, mit /D hingegen schon. Sachen gibt's....
Danke für die Bestätigung!
> Rainald Taesler:
>
>> Nein, es liegt an MKLINK.
>
> Ich hab's gerade noch mal getestet. Wir haben beide Recht:
> Es liegt am Parameter: Mit dem Parameter /J braucht's keine erhöhten
> Rechte, mit /D hingegen schon. Sachen gibt's....
> Da ich hier nur mit Junctions, nicht mit Symlinks arbeite, war mir
> das nie aufgefallen.
Rainald
Hans-Peter Matthess
Dec 12, 2011, 1:34:32 PM12/12/11
to
Rainald Taesler:
> Der OP arbeitet mit "Symbolischen Links".
Wobei man sich fragen könnte, warum er das macht. Wenn keine Netzwerkpfade
im Spiel sind, nimmt man Junctions.
> Der OP arbeitet mit "Symbolischen Links".
im Spiel sind, nimmt man Junctions.
Rainald Taesler
Dec 12, 2011, 2:13:41 PM12/12/11
to
Hans-Peter Matthess wrote:
> Rainald Taesler:
>
>> Der OP arbeitet mit "Symbolischen Links".
>
> Wobei man sich fragen könnte, warum er das macht. Wenn keine
> Netzwerkpfade im Spiel sind, nimmt man Junctions.
Da mußt Du ihn schon selber fragen <bg>.
> Rainald Taesler:
>
>> Der OP arbeitet mit "Symbolischen Links".
>
> Wobei man sich fragen könnte, warum er das macht. Wenn keine
> Netzwerkpfade im Spiel sind, nimmt man Junctions.
Rainald
Hans-Peter Matthess
Dec 12, 2011, 2:24:29 PM12/12/11
to
Rainald Taesler:
> Da mußt Du ihn schon selber fragen <bg>.
Ich denke, er hat die Frage schon verstanden, auch wenn sie scheinbar dir
galt. ;-)
> Da mußt Du ihn schon selber fragen <bg>.
galt. ;-)
0 new messages