| Zeile 21: | Zeile 21: | ||
--[[Benutzer:Dem epOS sein Linus|DesL]] 13:50, 28. Nov. 2010 (CET) | --[[Benutzer:Dem epOS sein Linus|DesL]] 13:50, 28. Nov. 2010 (CET) | ||
:Schau dir doch an, wie so ein Verzeichniseintrag aussieht. Mit 4 Bytes für die Dateigröße kommst du eben nur auf 4 GB. Aber kann es sein, dass Windows schon bei 2 GB Schluss macht? --[[Benutzer:Taljeth|Taljeth]] 17:01, 28. Nov. 2010 (CET) | :Schau dir doch an, wie so ein Verzeichniseintrag aussieht. Mit 4 Bytes für die Dateigröße kommst du eben nur auf 4 GB. Aber kann es sein, dass Windows schon bei 2 GB Schluss macht? --[[Benutzer:Taljeth|Taljeth]] 17:01, 28. Nov. 2010 (CET) | ||
| − | + | :: Theoretisch könnte man aber eine größere Datei schreiben und beim lesen, zählt man einfach die gelesenen sectoren und daraus kann man die dateigröße berechnen. --[[Benutzer:PNoob|PNoob]] 00:14, 29. Nov. 2010 (CET) | |
| + | ::: Das würde bedeuten das die Größe einer Datei immer auf ein Vielfaches der Cluster-Größe aufgerundet werden müsste. Wenn ein Programm eine Datei mit 4GB+20 Bytes anlegt und beim nächsten Öffnen ist die Datei dann 4GB+8kB groß was für Daten sollen in den fast 8kB zusätzlichen Bytes drin sein? Einfach mit 0x00 auffüllen dürfte sicher für die meisten Programme okay sein aber das kann man eben nicht garantieren. Ich persönlich fände es doof wenn das Dateisystem einfach so die Größe meiner Dateien aufrundet (mal ganz davon abgesehen das dann hinten ein paar zufällige Bytes drin sind). Außerdem müsste man nur um die Dateigröße zu ermitteln der gesamten Cluster-Kette folgen was schon etwas Aufwand bedeutet (vor allem bei großen Dateien mit sehr vielen Clustern). --[[Benutzer:Erik.vikinger|Erik.vikinger]] 12:16, 29. Nov. 2010 (CET) | ||