Findfirst findet Ordner wie System Volume Information nicht?

[richard_boderich]

Moin!

Warum findet Delphi Findfirst/Findnext keine Ordner wie z.B. "System Volume Information" ect. ? Kann dazu jemand einen Hinweis geben?

mfG Richard

[taaktaak]

Welche Attribut-Konstanten setzt du denn?

[richard_boderich]

momentan so

Delphi-Quellcode:

(SR.Name<>'.') and (SR.Name<>'..') AND ((SR.attr And fadirectory)<>0)

mfG Richard

[RavenIV]

Zitat:

Zitat von richard_boderich

Warum findet Delphi Findfirst/Findnext keine Ordner wie z.B. "System Volume Information" ect. ? Kann dazu jemand einen Hinweis geben?

Weil "System Volume Information" schreibgeschützt, System, versteckt und was-weiss-ich-alles ist.
Nicht mal ein Administrator darf das öffnen.

Was willst Du auch mit diesem Ordner?
Da steht nix interessantes drin.

[taaktaak]

Ungeachtet der Fragestellung, was du damit möchtest:

Wenn FindFirst die Parameter faDirectory+faSysFile+faHidden übergeben werden, dann werden diese Verzeichnisse auch gefunden :stupid:

[richard_boderich]

@RavenIV

Zitat:

Weil "System Volume Information" schreibgeschützt, System, versteckt und was-weiss-ich-alles ist.
Nicht mal ein Administrator darf das öffnen.

Ist mir bekannt, deshalb meine Frage ;)

Zitat:

Da steht nix interessantes drin.

für mich schon!

Zitat:

Was willst Du auch mit diesem Ordner?

gesicherte ADS Streams des System-Wiederherstellungsdienstes auflisten.

mfg Richard

[Luckie]

Dann wirst du aber erstmal mit administrativen Rechten, die Zugriffsberechtigungen anpassen müssen, damit du auch als Administrator den Ordner öffnen kannst.

[richard_boderich]

@taaktaak

Zitat:

Wenn FindFirst die Parameter faDirectory+faSysFile+faHidden übergeben werden, dann werden diese Verzeichnisse auch gefunden

Bist du dir da sicher? Diese Kombination habe ich auch schon ausprobiert?! Außerdem solltest du die Attribute niemals Addieren, sondern
Logisch verknüpfen wurde hier mal gesagt.

mfG Richard

[richard_boderich]

@Luckie

Du meinst also es liegt definitiv an den Zugriffsrechten ? Kein Findfirst Attribut-Fehler ?
Kann deine ADS Klasse vielleicht sowas?

mfG Richard

[taaktaak]

Hmmm, das Additionszeichen war nur eine textliche Darstellung. Obwohl, im Test habe ich's auch so gemacht!?
JA, bei mir werden die Verzeichnisse angezeigt. Die darin enthaltenen Dateien habe ich allerdings nicht heraussuchen lassen (und jetzt ist schon alles wieder perduto)

// edit: Im Beispiel der Delphi-Hilfe wird übrigens auch addiert :-D

[Luckie]

Zitat:

Zitat von richard_boderich

Kann deine ADS Klasse vielleicht sowas?

Was hat meine ADS-Klasse zum Auslesen und Bearbeiten von alternativen Datenströmen bei NTFS Dateisystemen mit dem Setzen von Zugriffsberechtigungen von Ordnern und Dateien zu tun?

[wido]

Zitat:

Zitat von richard_boderich

@taaktaak
Bist du dir da sicher? Diese Kombination habe ich auch schon ausprobiert?! Außerdem solltest du die Attribute niemals Addieren, sondern Logisch verknüpfen wurde hier mal gesagt.

Bei Win32 API werden die Parameter logisch verknüpft. Bei den meisten Delphi Funktionen (wie z.B. FindFirst) wird addiert.

[Muetze1]

Zitat:

Zitat von wido

Zitat:

Zitat von richard_boderich

@taaktaak
Bist du dir da sicher? Diese Kombination habe ich auch schon ausprobiert?! Außerdem solltest du die Attribute niemals Addieren, sondern Logisch verknüpfen wurde hier mal gesagt.

Bei Win32 API werden die Parameter logisch verknüpft. Bei den meisten Delphi Funktionen (wie z.B. FindFirst) wird addiert.

Was aber definitiv falsch ist, da sich die Konstanten aus den WinAPI Konstanten zusammen setzen und es so oder so eine Bittabelle ist und somit logisch verknüpft werden müssen.

Addier doch einfach mal ein Wert zweifach oder faAnyFile dazu, dann haste deine Begründung warum das falsch ist und man definitiv OR verwenden sollte.

Was mich mal interessiert: Wodrauf beruht deine Aussage das die Addition richtig ist? Die Hilfe hat genügend Fehler und ist keine sichere Basis.

[wido]

Zitat:

Addier doch einfach mal ein Wert zweifach oder faAnyFile dazu, dann haste deine Begründung warum das falsch ist und man definitiv OR verwenden sollte.

Wieso sollte ich bei der Verwendung von faAnyFile überhaupt irgend eine andere Konstante addieren oder aber bitweise verknüpfen? Und natürlich, wenn ich Konstanten doppelt und dreifach addiere, dann funktioniert es nicht. Ändert nichts daran, daß eigentlich der komplette Code von CodeGear die Konstanten addiert und auch in der Hilfe dies der einzig dokumentierte Weg ist.

Mal davon abgesehen, daß z.B. ein faSysFile or faHidden or faDirectory das Selbe ist wie ein faSysFile + faHidden + faDirectory.

[shmia]

Zitat:

Zitat von wido

[Wieso sollte ich bei der Verwendung von faAnyFile überhaupt irgend eine andere Konstante addieren oder aber bitweise verknüpfen? Und natürlich, wenn ich Konstanten doppelt und dreifach addiere, dann funktioniert es nicht. .

Es ist nun mal so, dass die File Attribute bitcodiert sind!
siehe: http://msdn2.microsoft.com/en-us/library/aa365740(VS.85).aspx (Hinweis: link kopieren, direkt anklicken geht nicht)

Bit 0 - read only
Bit 1 - Hidden
....

Wenn man bestimmte Bits aktivieren möchte muss man OR benützen.
Wenn man bestimmte Bits ausblenden möchte muss man AND NO benützen.
Das sind Grundlagen der Informatik.

Wenn man z.B. alle Dateien ohne Verzeichnisse finden möchte dann schreibt man:
faAnyFile AND NOT faDirectory

Zitat:

Zitat von wido

Ändert nichts daran, daß eigentlich der komplette Code von CodeGear die Konstanten addiert und auch in der Hilfe dies der einzig dokumentierte Weg ist.
Mal davon abgesehen, daß z.B. ein faSysFile or faHidden or faDirectory das Selbe ist wie ein faSysFile + faHidden + faDirectory.

Das ist nur ein Scheinargument. Wenn falsche Dinge im Internet verbreitet werden, bedeutet das nicht, dass sie damit richtig werden.

[Muetze1]

Zitat:

Zitat von wido

Wieso sollte ich bei der Verwendung von faAnyFile überhaupt irgend eine andere Konstante addieren oder aber bitweise verknüpfen?

Es war ein offensichtliches Beispiel. Schon allein wenn du das als Vorbelegung einer Variablen nimmst welche später dem FindFirst übergeben wird und dazwischen diese Variable noch angepasst wird, kann dies passieren.

Zitat:

Zitat von wido

Und natürlich, wenn ich Konstanten doppelt und dreifach addiere, dann funktioniert es nicht.

Und wenn du das schreibst, ist es dir doch ganz genau bewusst das es Bitkonstanten sind und man diese somit nicht addiert, gerade weil ein falsches Ergebnis rauskommt.

Zitat:

Zitat von wido

Ändert nichts daran, daß eigentlich der komplette Code von CodeGear die Konstanten addiert und auch in der Hilfe dies der einzig dokumentierte Weg ist.

Wobei sich CodeGear nicht rausnimmt unfehlbar zu sein und es gibt genug Falschaussagen in der VCL/Delphi Hilfe. Ich erinnere da nur an das case-insensitive IndexOf() bei TStrings.

Zitat:

Zitat von wido

Mal davon abgesehen, daß z.B. ein faSysFile or faHidden or faDirectory das Selbe ist wie ein faSysFile + faHidden + faDirectory.

not not true ist auch wieder true, trotzdem schreibt man's nicht.

[taaktaak]

Es ist schon erstaunlich. Da macht man jahrelang etwas nicht richtig. Es führt nie zu einem Fehler oder unkorrekten Ergebnis. Trotzdem ist es, nüchtern betrachtet, falsch. Die Diskussion hat mich überzeugt. Künftig wird's nur noch mit OR Verknüpft!

Bemerkenswert dabei, das man auch im Falle solcher (scheinbaren) Nebensächlichkeiten häufig noch etwas dazu lernen kann!
Vielen Dank allen Beteiligten!

[wido]

Schauts, wir brauchen darüber eigentlich nicht zu diskutieren.

CodeGear möchte, daß man die Werte addiert. Es ist so von ihnen dokumentiert und sie selbst handhaben es innerhalb des VCL Codes ebenfalls so. Das man es bitcodieren kann, hab ich nie bestritten. Wie gesagt, sollte das Bit bzw. die Bits nicht gesetzt sein, erhält man bei der Addition mit der Konstante den selben Wert wie bei nem OR. Allerdings bevorzuge ich im Zweifelsfall dann doch eher die dokumentierte Methode alleine schon deshalb um eine gewisse Zukunftssicherheit für meinen Code zu gewährleisten.

[Muetze1]

Zitat:

Zitat von wido

Allerdings bevorzuge ich im Zweifelsfall dann doch eher die dokumentierte Methode alleine schon deshalb um eine gewisse Zukunftssicherheit für meinen Code zu gewährleisten.

Rofl - ehrlich - schon allein dadurch baust du dir selber eine Unsicherheit für die Zukunft. Schon allein da CodeGear diesen Fehler mit spätestens D7 in der Hilfe umformuliert hat und die Abfrage von Attributen mit dem AND Operator erklärt.

Zitat:

Um ein Attribut zu testen, führen Sie eine AND-Verknüpfung des Attr-Feldes mit der Attributkonstante durch. Besitzt die Datei das betreffende Attribut, ist der zurückgegebene Wert größer als 0. Wurde beispielsweise eine verborgene Datei gesucht, ergibt der folgende Ausdruck true:

Delphi: (SearchRec.Attr and faHidden) <> 0.
C++: (SearchRec.Attr & faHidden) != 0.

Mir kommt es eher so vor, als wenn CodeGear für dich unfehlbar ist und du blind folgst. So lange man dir nicht sagt "stehen bleiben", gehst du weiter auf die Klippe zu, wider besserem Wissens.

Zitat:

Zitat von wido

CodeGear möchte, daß man die Werte addiert. Es ist so von ihnen dokumentiert und sie selbst handhaben es innerhalb des VCL Codes ebenfalls so.

Das Beispiel wurde spätestens mit Delphi 7 aus der Hilfe entfernt. Ansonsten sehe ich keine Stelle wo CodeGear das selbst so macht. Und in den VCL Codes nutzen sie immer "or", "and not" bzw. "and" im Zusammenhang mit diesen Attributflags. Nirgendwo, wirklich nirgendwo, habe ich diese Addition in den VCL Quellen im Zusammenhang mit diesen Attributflags gefunden.

FileIsReadOnly, FileSetReadOnly, etc machen dies so.

Das beste Beispiel ist sogar die erste Zeile der FindFirst Implementation von Codegear:

Delphi-Quellcode:

  faSpecial = faHidden or faSysFile or faVolumeID or faDirectory;

(Copyright (c) 1995-2002 Borland Softwrare Corporation) Der Schreibfehler ist Original!

Ich kann diese sture Haltung bezüglich überzeugender Argumente wirklich nicht verstehen - und ich finde über sowas muss man diskutieren. Schon grundlegend weil wir hier Informationen anbieten und damit verbreiten von denen viele andere lernen - oftmals still und leise durch die SuFu, google, etc. Von daher kann ich es nicht mit mir vereinbaren etwas gut zu heissen was definitiv und "bewiesener Maßen" falsch ist. Als das größte deutschsprachige Delphi-Forum und zusätzlich zu Delphi als Lehrsprache in den Schulen haben wir eine gewisse Verantwortung und somit muss man darüber diskutieren.

[wido]

Ok, da das Signal, das ich mit dem letzten Posting setzen wollte, offensichtlich nicht deutlich genug war:

E.O.D.

Du kannst Deine Zeit aber gerne noch weiter damit vertreiben mich davon zu überzeugen, daß ich Unrecht habe und Du nicht. Mein Standpunkt, daß ich bei 2 möglichen Methoden stets die nutze, die dokumentiert ist, wird sich dadurch nicht ändern:

Zitat:

Attributes can be combined by adding (Delphi) or or-ing (C++) their constants or values. For example, to search for read-only and hidden files in addition to normal files, pass (faReadOnly + faHidden) in Delphi or (faReadOnly | faHidden) in C++ as the Attr parameter. To include only normal files, pass zero for the Attr parameter.

[Muetze1]

Zitat:

Zitat von wido

Du kannst Deine Zeit aber gerne noch weiter damit vertreiben mich davon zu überzeugen, daß ich Unrecht habe und Du nicht. Mein Standpunkt, daß ich bei 2 möglichen Methoden stets die nutze, die dokumentiert ist, wird sich dadurch nicht ändern:

Wozu? Mir ging es um eine Erklärung und Richtigstellung für alle nachfolgenden Leser, Dokumentation der Unzulänglichkeit der Hilfe in diesem Falle. Ich bin nicht Priester o.ä. und es ist nicht meine Aufgabe. Ich gebe nur Ratschläge & Tipps und habe es zweimalig versucht - gut ist.

PS: Du bist nicht zufälligerweise Projektleiter oder CEO einer Firma?

[richard_boderich]

@Muetze1

Kannst du dir mal folgenden Aufruf anschauen?

Mein Findfirst...

Delphi-Quellcode:

if (FindFirst(ADirectory+AMask, faAnyFile,SR)=0) then´

und meine Auswertung zur Rekursion...

Delphi-Quellcode:

if (SR.Name<>'.') and (SR.Name<>'..') AND ((SR.attr And fadirectory)<>0)

faAnyfile sucht nach allem Files + Directorys. In der Rekursionsbedingung Werte ich ja mit

Delphi-Quellcode:

((SR.attr And fadirectory)<>0)

aus ob das Attribut faDirectory ist. Meine Frage wäre, ob diese Abfrage auch funktioniert, wenn ich ein Verzeichnis habe, was z.B.
versteckt ist. Also die Attribute faDirectory und faHidden besitzt oder z.B. faDirectory und faHidden und faSysfile.

Wenn nicht kannst du mir sagen wie ich darauf prüfen könnte?

mfG Richard

[Luckie]

Zitat:

Zitat von wido

Mein Standpunkt, daß ich bei 2 möglichen Methoden stets die nutze, die dokumentiert ist, wird sich dadurch nicht ändern:

Wie gerade gezeigt wurde, hat Borland / CodeGear die Dokumentation geändert (ich sage jetzt mal nicht "korrigiert"), was nun?

[Muetze1]

Zitat:

Zitat von richard_boderich

Meine Frage wäre, ob diese Abfrage auch funktioniert, wenn ich ein Verzeichnis habe, was z.B. versteckt ist. Also die Attribute faDirectory und faHidden besitzt oder z.B. faDirectory und faHidden und faSysfile.

Ja, der Code würde immer dann ansprechen, wenn das Attribut für ein Verzeichnis gesetzt ist. Welche Attribute zusätzlich gesetzt sind, geht in dieser Abfrage nicht mit rein.

Diese Bitmasken kannst du mit einer Menge übersetzen (wobei Delphi dies bei Sets andersherum sogar macht). Du prüfst nun damit nur ab, ob das Attribut "Directory" in dieser Menge ist. Ob andere Elemente in der Menge sind, fragst du ja nicht. Somit werden auch versteckte, als System etc. gekennzeichnete Einträge auch mit durchgelassen - Hauptsache das Bit für ein Verzeichnis ist gesetzt.

Wenn du dir die Konstanten anschaust (also faDirectory, faReadOnly, faSystem, etc), dann stellt man leicht fest, dass es immer nur einzelne Bits sind. Mit der AND Operation führst du ein binäres UND durch und maskierst damit alle anderen Bits, bis auf die gesetzten des 2. Parameters, aus. Da dein zweiter Parameter nur ein Bit gesetzt hat, ist nach der UND Verknüpfung entweder genau das Bit gesetzt oder gar keins.

Wir hatten gerade ein paar ausführliche Erklärungen dazu. Dort hatten wir alle zusammen das eigentlich ganz gut erklärt. Dann wird das bestimmt auch etwas klarer warum und wie das ganze funktioniert.

[richard_boderich]

besten Dank :)

mfG Richard