AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Win32/Win64 API (native code) Dateisystemcache invalidieren erzwingen
Thema durchsuchen
Ansicht
Themen-Optionen

Dateisystemcache invalidieren erzwingen

Ein Thema von Assarbad · begonnen am 12. Jan 2017 · letzter Beitrag vom 15. Jan 2017
Antwort Antwort
Seite 2 von 2     12   
Benutzerbild von himitsu
himitsu

Registriert seit: 11. Okt 2003
Ort: Elbflorenz
44.184 Beiträge
 
Delphi 12 Athens
 
#11

AW: Dateisystemcache invalidieren erzwingen

  Alt 13. Jan 2017, 14:19
Standardmäßig gibt es die doppelt, um bei Fehlern die Zweite nehmen zu können.
Aber das könnte man einstellen, von 1 bis mehr. Vorallem bei kleinen Disketten für viel Daten konnte man so ein paar KB mehr an Daten drauf bekommen, genauso wenn man die Clustergröße größer festlegte, wurde dadurch die FAT kleiner, weil es weniger Cluster zu verwalten gibt.

Das Doppelte betraf vorallem das Hauptverzeichnis und die AllocationTabelle, also das, wo drin stand welcher Cluster belegt ist und mit welchem er als nächstes verlinkt ist.
$2B or not $2B
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.234 Beiträge
 
#12

AW: Dateisystemcache invalidieren erzwingen

  Alt 13. Jan 2017, 22:10
Also die MFT zu parsen ist nur bedingt eine Option. Aus den von dir bereits genannten Gründen. Ist mir außerdem zu heikel sowas in einer Software einzusetzen wenn es Betriebssystemversionen betrifft die noch unterstützt werden. Wenn es um Systeme bis Vista geht, würde ich mich auch darauf einlassen, da man dort faktisch sicher sein kann, daß sich die entsprechenden Strukturen nicht retroaktiv ändern

FAT ist für mich im Großen und Ganzen kein Optimierungsziel, sondern maximal NTFS, reFS und Netzlaufwerke (unabhängig vom eigtl. Dateisystem).

[...] als sich überall mit FindFirstFile/FindNextFile einzeln durch alle Ebenen zu kämpfen.
Das ist nur bedingt richtig. Die Bremse bei FindFirstFile und FindNextFile ist ja, daß dort standardmäßig allenfalls wenige Dateiinformationen auf einmal gelesen werden. MSDN-Library durchsuchenFindFirstFileEx versucht das mit dem Flag FIND_FIRST_EX_LARGE_FETCH zu beheben, aber eben erst ab Windows 7. Damit werden dann die Informationen vieler Dateien in einem Zug gelesen und dann eben einzeln per FindNextFile zurückgegeben. Die Beschleunigung passiert aber dadurch, daß der Vorgang mit der hohen Latenz (Netzverkehr oder von Platte lesen) optimiert wird, indem man in einem Schwung viele Dateieinträge ausliest, statt nur sehr wenige. Indem man dann FindExInfoBasic benutzt, kann man noch ein paar Kopiervorgänge vermeiden (dann fällt der kurze Dateiname weg). Aber dann kann man eben auch direct die darunterliegenden Native API Funktionen benutzen. Und da will ich exakt austesten was genau wieviel Performanceschub bringt.
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#13

AW: Dateisystemcache invalidieren erzwingen

  Alt 14. Jan 2017, 11:04
Interessante Idee, aber wie soll ich
Zitat:
If the string ends with a wildcard, period, or directory name, the user must have access to the root and all subdirectories on the path.
verstehen? Auf unseren Servern haben wir ungefähr diese Struktur
irgendwas\Daten\Buchhaltung
irgendwas\Daten\Vertrieb
irgendwas\Daten\Boss

und auf den PCs des Vertriebs ist irgendwas\Daten\Vertrieb als Laufwerk P: gemappt und die Berechtigungen sind entsprechend eingestellt. Worauf bezieht sich das erwähnte "root"? ist das P:\* oder irgendwas\Daten\Vertrieb ?
Im letzteren Fall wäre FindFirstFileEx schlicht untauglich.

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Benutzerbild von Zacherl
Zacherl

Registriert seit: 3. Sep 2004
4.629 Beiträge
 
Delphi 10.2 Tokyo Starter
 
#14

AW: Dateisystemcache invalidieren erzwingen

  Alt 15. Jan 2017, 15:11
Worauf bezieht sich das erwähnte "root"?
Ziemlich sicher auf irgendwas\Daten\ . Bei Verwendung einer Wildcard am Ende des Strings benötigt die API dann natürlich auch die erforderlichen Rechte auf irgendwas\Daten\* , um Dateien in den Unterordnern suchen zu können. Die andere Möglichkeit ergibt - rein logisch betrachtet - zumindest wenig Sinn.
Projekte:
- GitHub (Profil, zyantific)
- zYan Disassembler Engine ( Zydis Online, Zydis GitHub)
  Mit Zitat antworten Zitat
Benutzerbild von Assarbad
Assarbad

Registriert seit: 8. Okt 2010
Ort: Frankfurt am Main
1.234 Beiträge
 
#15

AW: Dateisystemcache invalidieren erzwingen

  Alt 15. Jan 2017, 19:43
Also es gibt da ein gewisses Benutzerrecht SeChangeNotifyPrivilege:

Zitat:
Required to receive notifications of changes to files or directories. This privilege also causes the system to skip all traversal access checks. It is enabled by default for all users.

User Right: Bypass traverse checking.
Ich vermute mal der andere Kommentar bezieht sich auf alle Ausnahmefälle in denen die Benutzer dieses Recht nicht haben. Das System würde in diesem Fall für die jeweiligen Elternverzeichnisse bis zum Wurzelverzeichnis Zugriffsrechte prüfen. Man kann sich denken, warum dieses Benutzerrecht standardmäßig für alle Benutzer aktiviert ist.
Oliver
"... aber vertrauen Sie uns, die Physik stimmt." (Prof. Harald Lesch)

Geändert von Assarbad (16. Jan 2017 um 09:14 Uhr)
  Mit Zitat antworten Zitat
Antwort Antwort
Seite 2 von 2     12   


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:03 Uhr.
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz