staging.inyokaproject.org

DrScott schrieb:

kaputtnik schrieb:

Unter Windows ist die Pfadlänge auf 255 Zeichen beschränkt (bei Nutzung von 1-Byte-Zeichen)

Mir ist nicht klar, worauf Du hier hinaus willst: VFAT kodiert nach UTF-16. In diesem Encoding gibt es keine 1-Byte-Zeichen. Daher kann VFAT ja auch nicht mehr als 256 Zeichen.

Hmmm, hatte dich vorher falsch verstanden.

Das Beste wird sein, beide Angaben zu verwenden, also zB "255 Bytes (bis zu 255 Zeichen)" (war das nicht schon mal drin? 😉 ). Oder man schreibt: "Bis zu 256 Zeichen (256 Bytes)", für FAT wäre das dann "Bis zu 255 Zeichen (510 Bytes)"... ja, das gefällt mir. Die Hinweise darunter werde ich entsprechend überarbeiten (dann fällt auch der ominöse Satz: "Bei FAT-Dateisystemen sind immer nur bis zu 255 Zeichen möglich,..." weg...).

Vor lauter "Bytes" und "Zeichen" bin ich schon ganz irre... 😕 🙄 Ich hoffe, das wir diesen Abschnitt dann endlich abschließen können!

Bitte angucken...

Was mir jetzt noch nicht gefällt sind die Angaben bei max. Dateigröße und max. Partitionsgröße: Es heißt "von ... bis ..." aber außer bei ext2 steht nirgends, woran, oder warum das so ist. Das es Grundsätzlich mit der Blockgröße zusammenhängt ist mir schon klar. Das müssen wir aber irgendwo noch etwas verdeutlichen.

• Wie bekomme ich die verwendete Blockgröße eines Dateisystems heraus?

• Kann man den Zusammenhang erläutern, ohne auf Zylinder und Sektoren einzugehen?

Wieviele Zeichen sind 1 Byte?

Die Frage "Wieviele Zeichen sind 1 Byte?" klingt komisch.
Byte im Sinne von Bit-Kette, 8-Bit-Kette? Also: Wieviele Zeichen sind eine 8-Bit-Kette?
Ich hätte mich gefragt:
Wieviele Bytes sind/hat ein Zeichen? Wieviele Bytes braucht es, um ein Zeichen darzustellen?

gabi schrieb:

Wieviele Bytes sind/hat ein Zeichen? Wieviele Bytes braucht es, um ein Zeichen darzustellen?

Korrekt, ist besser!

kaputtnik schrieb:

Bitte angucken...

Werde demnächst noch ein paar Kleinigkeiten korrigieren... 😉

Was mir jetzt noch nicht gefällt sind die Angaben bei max. Dateigröße und max. Partitionsgröße: Es heißt "von ... bis ..." aber außer bei ext2 steht nirgends, woran, oder warum das so ist. Das es Grundsätzlich mit der Blockgröße zusammenhängt ist mir schon klar. Das müssen wir aber irgendwo noch etwas verdeutlichen.

Auch hier wäre ich für einen allgemeinen Kommentar, da es fraglich ist, ob die Details wirklich für alle Dateisysteme genau ermittelt werden können. Ausserdem stellt sich die Frage: Ist ein höherer Detailgrad wirklich notwendig?

• Wie bekomme ich die verwendete Blockgröße eines Dateisystems heraus?

Für die ext-Gruppe: dumpe2fs. Bei der Erstellung mittels mkfs.extX können die Größen manuell angegeben werden. Ansonsten werden die Größen irgendwie sinnvoll ermittelt.

• Kann man den Zusammenhang erläutern, ohne auf Zylinder und Sektoren einzugehen?

Erstmal ist ein Block ja nur eine Menge von Byte. Nicht mehr und nicht weniger. Das Dateisystem wird in Blöcke aufgeteilt, um einen vernünftigen Kompromiss zwischen eigentlicher Datenhaltung und dem Aufwand der dazu nötigen Verwaltung zu erzielen. Bei diesem Kompromiss geht es dabei sowohl um möglichst optimale Nutzung des Speicherbereichs als auch die Minimierung des nötigen Zeitbedarfs der Verwaltung. Das sind beides Bereiche, die durchaus Reibungspunkte aufweisen.
Je nach Größe des Speichers ist es nun sinnvoller, mehr oder weniger bzw. kleinere oder größere Blöcke zu unterstützen. All diese Bereiche haben oft eine prinzipbedingte Obergrenzen (wobei diese Obergrenzen sich oft an dem damals vorstellbaren sinnvollen Bereich orientierten ("Ein Computer wird niemals mehr als 640KiB benötigen...).

Hier ist n ganz guter Link, wenn auch anscheinend etwas älter: http://kris.koehntopp.de/artikel/unix/dateisysteme/node6.html

Oder Inode...

Wenn ichs richtig verstanden habe, könnte man es so formulieren: Neee... 😊 Habs versucht textlich zu beschreiben, aber ohne Diagramm kann man das nicht verdeutlichen!

Hab mich jetzt für einen ganz allgemeinen Text entschieden...

Hallo,

wenn es ein Einsteige-Artikel ist und bleiben soll würde ich auf Block, Inodes, Zylinder etc. nicht eingehen - das geht zu tief in die Materie. Außerdem sind die Default-Einstellungen zu 99% ja für alle hinreichend gut. ☺

Und: zum Thema Formatieren gibt es seit ca. 1 min einen eigenen Artikel: Formatieren. Kannst du im Dateisystem-Artikel gerne berücksichtigen.

Gruß, noisefloor

Ach da warst Du in letzter Zeit 😉

noisefloor schrieb:

wenn es ein Einsteige-Artikel ist und bleiben soll würde ich auf Block, Inodes, Zylinder etc. nicht eingehen - das geht zu tief in die Materie.

Steht ja auch so nicht drin... ein Link auf Inode schadet aber auch nicht.

Außerdem sind die Default-Einstellungen zu 99% ja für alle hinreichend gut. ☺

So stehts in etwa drin!

Und: zum Thema Formatieren gibt es seit ca. 1 min einen eigenen Artikel: Formatieren. Kannst du im Dateisystem-Artikel gerne berücksichtigen.

Ja, prima wenn man selber im Wiki-Team ist, nicht? Dann kann man einen Artikel innerhalb von 5 Tagen durchboxen 🙄 Andere Leute warten Wochenlang, das ihre Artikel endlich aus der Baustelle verschoben werden 👿 ... Mir hat mal ein Wiki-Teammitglied mitgeteilt, das das Team normalerweise eine Zeitlang (ne Woche oder so) wartet, bis fertige Artikel aus der Baustelle kommen, um sicherzugehen, das niemand mehr was zu meckern hat...

Tschulli, aber das regt mich halt n bissel auf.

BTT: Natürlich werden wir ein Plätzchen für einen Link zu Deinem Artikel finden...

Hallo,

[off-topic]

Tschulli, aber das regt mich halt n bissel auf.

Ja, kann man theoretisch. Und nein, trifft hier nicht zu. Normalerweise warten wir, ob 2-3 Tage kein (wichtiger) Kommentar mehr kommt, dann wird geschoben. Das trifft auf alle Artikel zu - egal von wem (trifft auf Formatieren BTW auch zu.)

Es kommt aber (zumindest bei mir) hinzu, dass ich meine wenigen (wenn ich überhaupt welche habe) Baustellen-Artikel nicht vergessen, bei den anderen 10/20/30/40 ... die fertig sind kann das aber schon mal vorkommen.

Wenn wirklich jemand den Eindruck hat, das Wiki-Team würde sich selber bevorzugen können wir das gerne in einem eigenen Thread diskutieren, weil dieser Eindruck (logischerweise) nicht entstehen darf, weil es nicht so sein soll / ist. [/off-topic]

Gruß, noisefloor

So, ich habe die Änderungen vorgenommen. Schau mal, ob Du einverstanden bist.

Ausserdem habe ich

Unter Linux ist die Pfadlänge auf 4096 Bytes beschränkt

in einem gnadenlosen Selbstversuch zu reproduzieren versucht. Ergebnis: Bei einer Pfadlänge von über 100000 Zeichen habe ich aufgegeben. Hier der Beweis:

xxx> /bin/pwd | wc
      1       1  102023
xxx> echo Ich habe wunde Finger > mag_nicht_mehr
xxx> cat mag_nicht_mehr 
Ich habe wunde Finger
xxx> df .
Dateisystem           1K‐Blöcke   Benutzt Verfügbar Ben% Eingehängt auf
/dev/sda2             22098548  19231324   1753524  92% /
xxx> mount | grep sda2
/dev/sda2 on / type ext3 (rw,relatime,acl,errors=remount-ro)

Keine Sorge: Ich habe keine wunden Finger: Wer selber etwas spielen will:

for i in $(seq 100); do mkdir 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789; cd 0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789; done

Vorher sollte man unbedingt das Prompt der Shell ändern, da diese sonst sehr schnell unglaublich träge wird:

export PS1="xxx> "

Aufgefallen ist mir, dass ungefähr ab einer Pfadlänge von 4000 Zeichen beim "CD" eine Fehlermeldung erscheint:

cd: error retrieving current directory: getcwd: cannot access parent directories: File name too long

Das ist aber eine Meldung der Bash und sie ist es auch, die hier wohl ein Problem hat. Ich vermute das der Buffer für das bash-interne "pwd" hier nicht groß genug ist. Deshalb nutzt ich oben ja "/bin/pwd", welches kein Problem hat.

"Find" hat damit keine Probleme:

find /home/xxxxxx/ -name 'mag_nicht_mehr' | sed 's/[0-9]*//g'

liefert

/home/xxxxxx///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////mag_nicht_mehr

Es ist allerdings richtig, dass der Dateiinhalt nicht mit absolutem Pfad abgerufen werden kann. Allerdings glaube ich auch hier, dass dies keine Beschränkung des Dateisystems oder VFS ist, da ja ohne weiteres "hinabgestiegen" werden kann. Die Meldung (File name too long) kommt meiner Meinung nach aber mindestens vom Kernel, da auch der Versuch scheitert, die Datei per Programm (Java) auszugeben. VFS kann ich aber nicht ausschließen...

DrScott schrieb:

So, ich habe die Änderungen vorgenommen. Schau mal, ob Du einverstanden bist.

Klasse... war ja auch nicht soo viel 😉

Ausserdem habe ich

Unter Linux ist die Pfadlänge auf 4096 Bytes beschränkt

in einem gnadenlosen Selbstversuch zu reproduzieren versucht. Ergebnis: Bei einer Pfadlänge von über 100000 Zeichen habe ich aufgegeben. ...

Aufgefallen ist mir, dass ungefähr ab einer Pfadlänge von 4000 Zeichen beim "CD" eine Fehlermeldung erscheint:

Das wird wohl mit den 4096 Bytes gemeint sein.

Ich bin der Meinung, das wir das drin lassen können. Auf zum nächsten Abschnitt...

Hallo,

Ich bin der Meinung, das wir das drin lassen können. Auf zum nächsten Abschnitt...

+1 - selbst 100 Zeichen sind ja schon ein Wert, den 99,9% der Nutzer nie haben werden. 4096 ist da schon sehr theoretisch.

Ich gehen davon aus, dass DrScott den Selbstversuch auch noch mit der ksh, zsh, dash usw. durchführt? 😀

Gruß, noisefloor

noisefloor schrieb:

Ich gehen davon aus, dass DrScott den Selbstversuch auch noch mit der ksh, zsh, dash usw. durchführt? 😀

Auch mein Masochismus kennt Grenzen... 😉 Aber ich finde es schon interessant, dass das Dateisystem (und darum geht es ja in erster Linie) durchaus mit solchen Monstern zurecht kommt. Wir lassen uns derzeit auf einen gefährlichen Spagat zwischen "Es geht hier um Dateisysteme > Es geht hier um Linux → so, noch ein Häppchen Windows und kräftig umrühren" ein.

Unter Linux ist die Pfadlänge auf 4096 Bytes beschränkt

ist in dieser Knappheit für mich einfach falsch (Es könnte vielleicht auch bei Windows falsch sein?). Mir ist klar, dass es ab 4k-irgendwas ungemütlich wird, aber es wird eben nicht "beschränkt". Ich versuche später mal noch die 4000er Grenze genauer zu fassen und überlege mir eine Formulierung mit der wir alle glücklich werden. 😉

Ausserdem interessiert mich, ab wann eine absolute Referenzierung nicht mehr möglich ist. Mal sehen...

noisefloor schrieb:

selbst 100 Zeichen sind ja schon ein Wert, den 99,9% der Nutzer nie haben werden. 4096 ist da schon sehr theoretisch.

(Mein Systemrekord liegt bei 243 Zeichen... 😉 )

Ok, man könnte den Abschnitt also auch einfach weglassen? Statt dessen lieber nur den Hinweis, dass es unter Linux möglich ist, Pfade zu erzeugen, die für Windows zu lang sind?

Abgesehen davon: Die ganzen schönen FAT-Windows-Ausnahme-Abschnitte müßte man auch nochmal gegen NTFS prüfen... Kann man FAT und NTFS bezüglich dieser Abschnitte über einen Kamm scheren oder brauchen wir auch noch Sonderbehandlung für NTFS?

Hallo,

Kann man FAT und NTFS bezüglich dieser Abschnitte über einen Kamm scheren oder brauchen wir auch noch Sonderbehandlung für NTFS?

IMHO reicht "dünn drüber". Für "produktiv" nimmt wohl (hoffentlich) kein Linux-Nutzer FAT oder NTFS, und beim Datenaustausch - sei es HD-Partition oder USB-Stick - kann man wohl mit ein paar Einschränkungen leben.

Außerdem ist hier ein Linux-Wiki. 😉

Gruß, noisefloor

DrScott schrieb:

Unter Linux ist die Pfadlänge auf 4096 Bytes beschränkt

ist in dieser Knappheit für mich einfach falsch (Es könnte vielleicht auch bei Windows falsch sein?).

Es ist wirklich blöd, das das nirgendwo wirklich zu finden ist. Dabei sollte doch alles offen sein... Naja, ich finde auch, das Du es hier etwas übertriebst. Klar, es soll nichts falsches drinstehen, aber wenn diese beschränkung vom Kernel abhängt, müsstest Du das ganze procedere auch für verschieden Kernel-Versionen ausprobieren und dann kommt man vom hunderste ins tausendste. Eigentlich soll ja mit den zwei Dingen nur gesagt werden: Linux kann mehr 😉 😊

noisefloor schrieb:

IMHO reicht "dünn drüber". Für "produktiv" nimmt wohl (hoffentlich) kein Linux-Nutzer FAT oder NTFS, und beim Datenaustausch - sei es HD-Partition oder USB-Stick - kann man wohl mit ein paar Einschränkungen leben.

+1 Und wer kommt tatsächlich an solche Beschränkungen heran? Wohl nur absolute Poweruser... (will ja jetzt keinen angucken 😉 )

@ DrScott: Teste nur. Wenn ein paar bedeutende Dinge dabei herauskommen, können wirs (Du 😬 ) ja noch einbauen.