Sparse-Datei

[MicMic]

Hallo,
habe mir dazu eine Micrsoft-Seite ins deutsche übersetzt und hab's halbwegs verstanden :)

Irgendwo las ich, dass es zu Problemen führen kann, wenn man solche Dateien kopiert und das Ziel mit Sparse-Dateien nicht umgehen kann. Auf der Microsoft Webseite steht jedoch auch:

"Die meisten Anwendungen kennen keine Sparse-Dateien und erstellen keine Sparse-Dateien. Die Tatsache, dass eine Anwendung eine Sparse-Datei liest, ist für die Anwendung transparent."

Ein paar Fragen... vielleicht kennt sich jemand aus.

Gibt's eigentlich irgendwo im Windows-System Sparse-Dateien?
Wenn nicht, wie erstelle ich eine zu Testzwecken?

Es geht eigentlich darum, dass ich eine Art Datei-Commander schreibe und mit Dateien arbeite, sprich sie lösche/kopiere/verschiebe usw.

Ich kann wohl mit dem Flag "FILE_ATTRIBUTE_SPARSE_FILE" prüfen, ob es sich um so eine Datei handelt. Vielleicht ist es hier wichtig, wie ich solch eine Datei kopiere/verschiebe? Es gibt ja sicherlich so manche verschiedene API-Funktionen für Dateioperationen. Vielleicht gibt es dafür spezielle Funktionen für Dateioperationen? Evtl. das Ziel dafür prüfen? Ich könnte mir vorstellen, dass Windows intern vieles übernimmt, wenn es um solche Dateien geht. Aber ich Grunde kenne ich mich nicht aus, habe nur darüber gelesen, dass es solche Dateien gibt. Wo es diese gibt, in welcher Praxis usw. alles mal wieder Neuland. Ich bin mir nur nicht im klaren darüber, ob ich mich damit weiter beschäftigen muss.

Michael

[himitsu]

Wo ist eigentlich das Problem?


Eine Sprase-Datei ist eine Datei mit "Lücken", also wo es Bereiche gibt, denen kein Speicherplatz zugewiesen ist.
Und ja, mit FILE_ATTRIBUTE_SPARSE_FILE kann man Dateien darauf prüfen.
TSearchRec.FindData.dwFileAttributes oder TSearchRec.Attr, wobei es egal ist, ob mit FILE_ATTRIBUTE_SPARSE_FILE oder durch ein selbstdefiniertes

Delphi-Quellcode:

const faSparseFile = $00000200;

.



Wenn beim Kopieren das Zielsystem kein Sparse kann, dann wird das einfach ersetzt,
genauso, wie alle Programme "transparent" drauf zugreifen können.

Wenn irgendjemand einen ausgelassenen Bereich lesen will, dann wird das vom Windows durch viele Nullen (#0) ersetzt.
Programme, welche beim Lesen mit SparseFiles umgehen können, überspringen dagegen solche Bereiche und versuchen garnicht sie zu lesen, weil sie ja wissen, dass dort nicht ist.


Und du hast überall im System SparseFiles.
z.B. die NTFS-Komprimierung nutzt das.
Diese Dateien werden Blockweise komprimiert (z.B. je 64KB), aber Blöcke bleiben "logisch" an ihrem Platz, wobei die ungenutzten Bereiche (Blockgröße-KomprimierteBlockgröße) als Sparse physisch von der Platte entfernt werden.
So kann in der Datei rumgeschrieben werden, ohne dass nachfolgende Blöcke verschoben werden müssen, auch wenn sich die komprimierten Blocklängen ändern.

Das ist auch der Grund, warum es auf Dateisystemen mit zu großen Clustern keine Kompression gibt, da dort durch Sparse keiner oder nicht genügend Speicher eingespart/ausgeschnitten werden kann.
https://blogs.msdn.microsoft.com/ntd...s-compression/

[MicMic]

Naja, ich weiß nicht wo das Problem ist, deshalb frage ich, ob es ein Problem sein oder werden kann :)
Gut das beim kopieren alles ersetzt wird.
Dann muss ich mich wirklich nicht drum kümmern

Solche Dateien hab ich schon versucht zu finden aber habe keine gefunden.
Habe aber inzwischen eine mit "fsutil sparse setflag test.txt" gesetzt um zu wissen, ob dies mit "FILE_ATTRIBUTE_SPARSE_FILE" erkannt wird. Das geht aber ich brauche es ja eigentlich nicht wirklich.

Danke für die Info

Michael

[himitsu]

Zitat:

Zitat von MicMic (Beitrag 1409103)

Solche Dateien hab ich schon versucht zu finden aber habe keine gefunden.

Joar, ist schon ein bissl blöd, dass CompressedFiles nur als Compressed aber nicht als Sparse markiert sind, auch wenn sie es intern nutzen. :stupid:

Aber ja, fast nirgendwo wird diese Technik benutzt.

Sowas ist vorallem auch nur dann sinnvoll, wenn Dinge an harten Speicheradressen in der Datei liegen und viele Plätze frei sind.
z.B. bei einer Map/Matrix, wo die Teile eine feste Größe haben und schnell/direkt adressiert werden können sollen. (einige DBMS könnten sowas verwenden)
Oder als "Kopierschutz", wie man es auch von CDs/DVDs kennt. (die Daten/Lizenzinfos sind in extrem großen Dateien, auch wenn diese eigentlich fast leer sind, bzw. der Dateiinhalt mehrfach verlinkt/dupliziert ist)

Auch beim Download großer Dateien wäre sowas praktisch, wenn hier mit mehreren Threads und/oder an Zufallspositionen geladen wird.
Nur kenn ich da auch kein Programm, welches es nutzt, und somit vorher die Datei in voller Größe mit 0 gefüllt erstellt. (0 ist das, womit Windows automatisch auffült, wenn man hinter dem Dateiende schreibt)




Sowas Ahnliches, was SparseFiles machen, wird auch bei der Deduplizierung verwendet. (hier zusätzlich noch eine LinkListe in den Metadaten der Datei)
Früher gab es nur HardLinks, also wo mehrere Dateien auf den selben Speicher/Dateiinhalt zeigten. (1111)
Inzwischen ist sowas auch für Dateiteile möglich, welche untereinander verlinkt sein können.
Nur hier gibt es wirklich enorme Probleme, da ein paar Programme damit nicht umgehen können und dann den Dienst verweigern ... z.B. SVN, wo Turtoise knallt, wenn es lokal auf solche Dateien trifft.
Blöd, dass hier auf ein "Attribut" falsch geprüft wird und SVN dann einen Fehler wirft "E270001: Symlinks are not supported on this platform", obwohl auch hier die Schreib-/Lesezugriffe vom NTFS-Treiber aufgelöst werden und es dem Programm eigentlich vollkommen egal sein kann. :wall:

1111: Wobei das eigentlich alle Programme behandeln sollte, denn wenn der Inhalt einer Datei geändert wird, ändert sich auch die andere Datei, da kein automatisches CopyOnWrite.
Aber gerade das prüft kein mir bekanntes Programm. :lol: :freak: