Findfirst liefert mir . und ..

lkz633 · Verfasst: Di 11.02.03 12:17

Hallo, ich möchte alle Dateien eines ordners löschen. Habe dazu folgenden code:

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:

......
  try
    try
      filelist:= tstringlist.Create;
      if FindFirst(extractfilepath(paramstr(0))+'temp\*.*',faAnyFile,Results)= 0 then
      repeat
        filelist.Add(extractfilepath(paramstr(0))+'temp\'+Results.Name);
      until FindNext(Results) <> 0;
      for i:= 0 to filelist.Count-1 do
        deletefile(filelist.Strings[i]);
    finally
      FindClose(Results);
      filelist.Free;
    end;
  except
    ........
  end;
  removedir(extractfilepath(paramstr(0))+'temp\');

Das klappt auch wunderbar, ich habe mir nur mal mit showmessage(Results.name) die Dateinamen anzeigen lassen, da bekomme ich als erstes . ; dann bekomme ich ..; und dann die Dateinamen. Trotzdem funktioiert der code einwandfrei. Warum ? Theoretisch übergebe ich doch dann auch . und .. an deletefile, und dnn muss es doch zu einem Fehler kommen !

Dank und Gruss
lkz633

Ehemaliges Mitglied Erhaltene Danke: 1

Aus dem Grund nimmt man ja auch "." und ".." aus.

"." ist das aktuelle Verzeichnis, in dem du dich gerade befindest. Einfach mal ausprobieren -> MS-DOS-Box auf und eintippen

markieren

Quelltext

1:

dir .

".." ist das übergeordnete Verzeichnis

markieren

Quelltext

1:

cd ..

Ist also kein Fehler sondern ganz in Ordnung. Du musst nur vor dem Hinzufügen der Ordnernamen prüfen, dass dieser Name nicht "." und nicht ".." ist. Eine Prüfung wie

markieren

Quelltext

1:	if(Results.Name[1] <> '.') ...

reicht leider nicht aus, da man ja auch Ordner mit führendem Punkt erstellen kann.

lkz633 · Verfasst: Di 11.02.03 12:42

Ah, super, wieder was gelernt ,danke:-)

Aber wiso führt das dann nicht zu einem Fehler wenn ich . und .. deletefile übergebe?

Gruss
lkz633

UGrohne · Verfasst: Di 11.02.03 13:05

Hmm, was wäre, wenn DeleteFile jetzt eine rekursive Funktion wäre, die gesamte Ordner löscht? Dann wäre die komplette Platte leer, oder?

Ich hatte mal ein ähnliches Problem unter Linux, in meinem Verzeichnis waren lauter Dateien/Verzeichnisse mit . vorne dran, die ich nicht gebraucht habe, dann hab ich einfach rm -R .* oder so gemacht, ihr könnt euch sicherlich vorstellen was passiert ist, der Param -R hat mir dann alles im übergeordneten Verzeichnis gelöscht, von da aus, ist er wieder eins höher... usw bis zum Root halt

Gut zu wissen, dass . und .. auch von find zurückgegeben werden, da kann man sich ne Menge Ärger ersparen....

Gruß

Ehemaliges Mitglied Erhaltene Danke: 1

Also, zumindest im MS-DOS-Modus klappt das Löschen (Edit ->) aller Dateien eines kompletten Ordners auch kurz mit

markieren

Quelltext

1:

del.

Rekursiv ist der Löschbefehl -zum Glück!- nicht.

Warum das Löschen nicht funktioniert, wenn lkz633 den Punkt oder die beiden Punkte angibt, würde ich auf die Funktion "DeleteFile" schieben. Die wird wohl einen Datei- und keinen Ordnernamen erwarten.

Ich persönlich ziehe aber SHFileOperation vor, weil man sich die Arbeit mit dem Suchen der Dateien spart, und weil man eine vernünftige Anzeige -wie vom Explorer gewohnt!- hat. Na ja, und du kannst auch mehr als einen Ordner angeben.

Ehemaliges Mitglied Erhaltene Danke: 1

UGrohne hat folgendes geschrieben:

Ich hatte mal ein ähnliches Problem unter Linux, in meinem Verzeichnis waren lauter Dateien/Verzeichnisse mit . vorne dran, die ich nicht gebraucht habe, dann hab ich einfach rm -R .* oder so gemacht, ihr könnt euch sicherlich vorstellen was passiert ist, der Param -R hat mir dann alles im übergeordneten Verzeichnis gelöscht, von da aus, ist er wieder eins höher... usw bis zum Root halt

Da ist dir sicher ein anderer Fehler unterlaufen, denn

markieren

Quelltext

1:

rm -r .*

würde alle Verzeichnisse und Unterverzeichnisse im aktuellen Ordner löschen, die mit einem Punkt beginnen.
Der Punkt steht, IMHO, für versteckte Dateien, usw. Quasi das "-h"-Attribut von Windows. Die Anweisung dürfte aber nicht in den übergeordneten Ordner springen.

Um alles auszuradieren, hättest du eigentlich

markieren

Quelltext

1:

rm -r /*

schreiben müssen.

UGrohne · Verfasst: Di 11.02.03 14:21

Hab mich geirrt, es war bei mir net rm, sondern chmod ug+rw -R .*

So und dieser Befehl wurde immer in das nächsthöhere Verzeichnis "gelupft" und hat mir damit damals mein etc-Verzeichnis verschandelt, und ich fragte mich noch, warum das so lange dauert *g*. Aber ich denke, dass es mit rm auch gehen würde, aber ich probiers lieber net aus.

Gruß

Ehemaliges Mitglied Erhaltene Danke: 1

UGrohne hat folgendes geschrieben:

Hab mich geirrt, es war bei mir net rm, sondern chmod ug+rw -R .*

CHMOD? Kann man mit CHMOD Dateien löschen?

Ich habe zwar kein Linux parallel laufen, aber ich behaupte jetzt mal, dass man mit CHMOD nur die Zugriffsrechte an Dateien ändern kann. So richtig erschließt sich mir der Sinn des o.g. Befehls nicht, da ich eigentlich davon ausgehe, dass man mit

markieren

Quelltext

1:

ug+rw

das Lese- und Schreibrecht für den Eigentümer und die Gruppe, der er angehört, einstellt; für alle Dateien, die mit einem Punkt beginnen. Nur das

markieren

Quelltext

1:

-R

gibt in dem Zusammenhang keinen Sinn.

Erklär´s mir. Oder finde eine dritte Möglichkeit, wie du deine Verzeichnisse gelöscht haben könntest ... :wink:

UGrohne · Verfasst: Di 11.02.03 16:37

LOL, ok ich erklärs dir:

Ich hab damals nicht meine Verzeichnisse gelöscht, ich wollte die Zugriffsrechte ändern.... das -R am Ende bedeutet das gleiche, wie beim Löschen, also recursive, er geht jedes Verzeichnis durch.

Und genau das ist das Problem, er ging JEDES Verzeichnis durch. . war ja net schlimm, aber .. hat ja dann dafür gesorgt, dass er dieses Verzeichnis komplett durchging. Tja und dann war er im Root und von da aus gings in /etc ... so und weißte was passiert, wenn Du mit den Rechten im etc-Verzeichnis rumspielst??? Sehr, sehr viel.... ok, später dann gar nix mehr. Aber als erstes funktionieren einige Sachen nicht mehr, bringen Fehlermeldungen, dann gings soweit, dass ich mich nicht mehr unter einem anderen User als root anmelden konnte.... So ist das eben.... Und dann versuch mal rauszufinden, wie die ursprüngliche Rechtevergabe in etc aussieht..... so ziemlich unmöglich.....
Fast jede Software unter Linux will ganz exakte Rechtevergabe in etc, z.B. die shadows-Datei. Wird die verwendet, und ist sie für andere Les-/Schreibbar dann verweigert die Bash die Anmeldung, weil die Datei ja nicht mehr sicher ist.... sche*** Sicherheit *g*.

Hab mich vll. etwas undeutlich ausgedrückt, ich hoffe das verdeutlicht jetzt etwas meine damalige Situation.

Gruß

Ehemaliges Mitglied Erhaltene Danke: 1

UGrohne hat folgendes geschrieben:

Hab mich vll. etwas undeutlich ausgedrückt, ich hoffe das verdeutlicht jetzt etwas meine damalige Situation.

Undeutlich trifft den Nagel auf den Kopf. :wink:

Zitat:

... ihr könnt euch sicherlich vorstellen was passiert ist, der Param -R hat mir dann alles im übergeordneten Verzeichnis gelöscht, ...

vs.

Zitat:

Ich hab damals nicht meine Verzeichnisse gelöscht, ich wollte die Zugriffsrechte ändern.

Vor Gericht hättest du jetzt ein Verfahren wg. Falschaussage am Hals. :twisted:

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme