Hallo,

auf dem Webserver befindet sich eine Datei mit der Größe 2,5 KB (2.518 Bytes) laut Cyberduck und der Finder meint, die Datei sei 4 KB (2.566 Byte) groß.

Warum ist da eine so große Differenz?

Ich habe auch schon mal den Effekt beobachtet, daß eine Datei größer wurde (laut Info) obwohl Inhalt entfernt wurde.


Ich find das irgendwie paradox.

Das hat nichts mit einem "Zehnersystem" zu tun, sondern mit der Blockgröße des Dateisystems. Und die ist bei HFS+ z.B. 4 KByte. So belegt also auch eine kleine Textdatei von 3 Byte 4 KByte Speicher auf dem Speichermedium.

Ist bei anderen Dateisystemen, wie etwa NTFS, sehr ähnlich: auch bei NTFS ist die Standardblockgröße 4 KByte.

Bei HFS übrigens waren damals maximal 65536 Blöcke pro Volume möglich. Bei einem 1-GByte-Volume war dann ein Block bereits 16 KByte groß. War einer der großen Vorteile von HFS+ ab Mac OS 8.1.

Mit dem Zehnersystem hat das nichts zu tun.

Die Differenz zwischen 2.566 und 2.518 Bytes kann daran liegen, dass der Finder in bestimmten Anzeigen auch erweiterte Attribute und Forks in die Größe mit einrechnet. FTP-Programme können mit solchen Feinheiten nicht umgehen und zeigen nur die Größe des reinen Datenzweigs einer Datei an.

Die Differenz zwischen 4 KB und 2.566 Byte liegen an einem Übersetzungsfehler in der deutschen Oberfläche des Finders. In der englischen Originalfassung heißt es "4 KB on disk". An dieser Stelle zeigt der Finder also die verbrauchte Blockgröße auf dem Speichermedium an. In Klammern steht die eigentliche Größe der Datei. In der deutschen Fassung fällt dieser Unterschied unter den Tisch.

Nur nebenbei: auch ext4 arbeitet mit einer Standard-Blockgröße von 4 KByte. Wenn der Webserver also darunter (samt Linux) betrieben wird, dann belegt die 2,5-KByte-Datei dort im Dateisystem ext4 ebenfalls 4 KByte. Was Dir via FTP präsentiert wird, ist wieder eine andere Sache.

Marcel Bresink
Klar, das mit dem Forks usw. kommt bei der Differenz bei den Angaben in den Klammern noch hinzu.

Ich dachte, dom_beta wollte in erster Linie auf die 2,5 vs. 4 KByte hinaus.

schaut mal, der Ordner "HP" ist das Original und "Kopie HP" die Kopie.

Und dem Ordner "Kopie HP" habe ich probeweise eine Datei entfernt, die 8 KB (694 Byte) groß war und der Ordner "HP Kopie" ist größer als das Original?!

HP Kopie: 29,8 MB (22.858.136 Byte)
HP (Original): 29,8 MB (22.846.538 Byte)

wie geht das denn?

                           .DS_Store

Ein mal einen Ordner in 'Neuer Ordner Kopie' erstellt
und gleich wieder gelöscht.

Mäuschen, Du bist die Beste!
Selbst für die wirklich wichtigen Fragen der User (schließlich sind Festplatten so wahnsinnig teuer geworden!
Wer kann sich heute noch 4kB leisten?) hast Du eie kompetente Antwort.

Ich danke Dir für Deine Teilnahme hier im Forum!

Vor allem Danke ich Dir für Deine Scriptkenntnisse!

Oh Mann seid ihr dämlich!

Es geht nicht um Festplattenspeicher sondern um den Speicherplatz auf dem Webserver.

Diejenigen Personen, dessen HP ich mache, haben nicht das große Geld und folglich kostet mehr Speicher eben mehr Geld.

Mann Mann Mann...

4KB machen auch die Welt aus.

Typischer dom_beta-Thread.

Noch blöder als ich dachte.

Traffic ist dir wohl auch unbekannt was?

Oh, Mann was bist du dämlich!

Zeigst /Users/dominique/Desktop

weinst aber über web space & traffic

eben, der Inhalt soll doch eben auch den Webspace, klingelt's?

Entferne doch die .DS_Store vor dem upload

Mann, Mann, Mann

Dann mach mit DSWipe die .dsse weg.

Auf den Traffic dürfte es übrigens keinen Einfluss haben, außer du bindest die .DS_Store Datei in deine HTML/XHTML Dateien ein, wovon ich aber mangels Sinn abraten würde.

es geht darum, den exakten Speicherverbrauch der gesamten Homepage zu ermitteln.

Und wenn der Besucher alle Seiten besucht, müssen diese Dateien heruntergeladen werden. Deshalb ist es für Webdesigner wichtig, keine Tabellen als Layout zu verwenden, da dies die Dateien unnötig aufbläht.

Und zusätzlich soll die Webseite so schnell wie möglich geladen werden; unnötiger Ballast verhindert dies und genau deshalb ist es für mich wichtig zu wissen, wie viel Speicherplatz verbraucht wird und dafür brauche eine exakte Byteangabe des OS.

So ist es!

Siehe auch entspr. Filter-Einstellungen im beigefügten Screenshot für den Download vom Server und den Upload zum Server bei Cyberduck (neben den .DS-Store-Dateien sind da auch noch ein paar andere Dateien mit voreingestellt, die standardmäßig nicht mit transferiert werden sollen und deren Transfer unterdrückt wird auf ihrem Weg vom und zum Server. Die beiden Listen ist beliebig edietier- und erweiterbar):

Ein typischer dom_beta halt (sorry, dom_beta). Unbeholfen und kompliziert im Denken bis es manchmal wehtut...

Das man für Layouts heute divs statt tables verwendet hat ganz andere Gründe, und oft sind die resultierenden Dateien einige Bytes größer als entsprechende Tabellen-Layouts.

Wenn du den Speicherplatz auf dem Server wissen willst musst du es auf dem Server messen. Warum, steht hier im Thread weiter oben.

Mach dich locker, wenn du Platz sparen willst, kümmere dich um die Größen der Bilder. Es gibt diverse Tools, um das letzte rauszuholen, zum Beispiel ImageOptim

Richtig.

Tabellen bitte nur dort, wo Inhalt vorhanden ist, den man von seiner Semantik her sinnvollerweise tabellarisch darstellt. Tabellen für reine Layoutzwecke sollten nach sovielen Jahren Aufklrung und Erkenntnisgewinn eigentlich ein striktes No-Go sein.

Wenn man's richtig macht, eigentlich nicht. Nur dann behältst Du recht, wenn man's dilletantisch oder im besten Falle völlig unwissend anstellt und ungeschickt unnötig verkompliziert und verschachtelt. Eine Tabelle verbraucht notgedrungen immer mehr Markup-Bytes als andere Nicht-Tabellen-Markup-Auszeichnungen. Weil sie aus mehr Bestandteilen besteht, die nicht wegkürzbar sind.

Ja. Doch kann man auch per remote auf einen Server drauf und sich die tatsächlichen Ist-Werte ausgeben lassen. Entweder mit einem guten FTP-Programm. Oder per Shell-Zugriff z.B. via SSH.

Und vor allem: verwende möglichst schlankes, auf das Wesentliche reduziertes valides Markup, schon allein das bringt eine ganze Menge bzw. schlägt sich unmittelbar in der Ladezeit und der Rendering-Zeit einer Webseite wider. Und auch ganz sicher in den Transferkosten. Reduzierter Umfang, der bewegt wird, braucht weniger schnell angemietete Leitungskapazität und vereinbarten Höchst-Traffic auf als wenn man damit sorglos und allzu spandabel rumast.

Zudem kann man HTTP Transfer-encoding benutzen und den Webserver anweisen, Inhalt während des Transports vom Server zum Empfänger per gzip zu komprimmieren. Der Browser dekrommiert solche Dateien dann automatisch, während er sie empfängt. Vorteil: geringerer Traffic, weil alle Daten gzip-komprimmiert durchs Netz gehen. Kleiner aber verschmerzbarer Nachteil: der Browser braucht eine Mikrosekunde, um diese Daten nach dem Empfang zu entpacken. Dafür sind sie nach dem Entpacken dann schlagartig da. Bilder lassen sich auf diese Weise zwar schlecht noch mehr komprimmieren, da sie binär sind und deshalb sinnnigerweise vorher schon kleingerechnet werden sollten. Aber alle Dateien, die irgendwie was mit reinem Text zu tun haben (HTML, XML, SVG, CSS, etc. pp.), lassen sich via HTTP Compression, auch genannt Content Transfer Encoding (bei Apache mittels des eingebauten Apache-Moduls mod_gzip) richtig schön vor dem Versand zusammenstauchen. Die Browser entpacken diese Daten dann automatisch und ohne dass der Benutzer davon was mitbekommt.

Auf diese Weise lässt sich Traffic richtig schön auf ein Minimum reduzieren, was die Grundlast angeht.

Siehe dazu auch:

Wikipedia: Chunked transfer encoding
Wikipedia: List of HTTP header fields

IANA: Hypertext Transfer Protocol (HTTP) Parameters
Mozilla: performance: HTTP Compression

Die HTTP header

Accept-Encoding: gzip,deflate
Content-Encoding: gzip
Transfer-Encoding: chunked

im Frage-Antwort-Spiel zwischen Client und Server erzählen, ob Kompression eingeschaltet und nuztbar ist (gzip bei Apache 1.x, deflate seit Apache 2.x) oder nicht (chunked).

Bei einem Apache 1.*-Server kann man Kompression über das mod_gzip-Modul erreichen, seit Apache 2.* in der Welt ist, läuft das über das Modul mod_deflate. Siehe auch http://localhost/manual/mod/mod_deflate.html oder auch online auf der Apache-Webseite: .

Beispiele dazu und wie man's konfiguriert und aktiviert gibt ausführlich das Apache-Manual lokal oder online (siehe gegebene URLs).

Es gibt 1000 Gründe, divs zu setzen, deren Sinn sich dem Hobby-Bastler nicht erschließt.

Aber bitte erspare mir eine Antwort, sie interessiert mich nicht.

Und selbst Profis (oder welche, die sich dort hinzurechnen), setzen oder verschachteln manchmal divs unnötigerweise, obwohl es die Hälfte davon oder gar noch weniger auch getan hätten... Manchmal fällt es ihnen auch selbst verspätet auf, nur lassen sie es dann nicht selten aus unterschiedlichen Gründen dann so stehen.

quatsch. wen die dsstore nicht verlinkt sind, werden die nicht heruntergeladne.

grosser quatsch. man sollte aus anderen gruenden keine tabellen fuer layout nehmen. dateigroesse hat nix damit zu tun.

auch quatsch. die geschwindigkeit der darstellung hat nur in sehr geringem masse etwas mit der dateigroesse zu tun. andere faktoren sind da ausschlaggebender.