ubuntuusers.de

DrScott schrieb:

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

ist in dieser Knappheit für mich einfach falsch

Wie wäre es mit:
Linux beschränkt sich bei der Pfad-Erstellung auf eine Pfadlänge von ...
Windows beschränkt sich bei der Pfad-Erstellung auf eine Pfadlänge von ...

Die Selbstbeschränkung von Windows gilt für fat und auch für ntfs.

Der Unterschied ist für mich der:
Linux: /255/255/255/255/.../255 (praktisch kein Limit: 4096 = ungefähr 16x255)
Windows: \x\y\...\z mit x+y+...+z = max 255 (mit aussagekräftigen Ordner- und Dateinamen ist man schnell am Limit)

kaputtnik schrieb:

Naja, ich finde auch, das Du es hier etwas übertriebst.

Ja, einer muss diesen undankbaren Job ja übernehmen... 😉

noisefloor schrieb:

Für "produktiv" nimmt wohl (hoffentlich) kein Linux-Nutzer FAT oder NTFS

Erwischt! Ich nutze eine NTFS-Partition auf einem reinen Linux-System. Es gibt auch einen sehr guten Grund dafür, etwas spezielles, was man mit Linux-Dateisystemen nicht so einfach hinbekommt... 😉

gabi schrieb:

Wie wäre es mit:
Linux: /255/255/255/255/.../255 (praktisch kein Limit: 4096 = ungefähr 16x255)
Windows: \x\y\...\z mit x+y+...+z = max 255 (mit aussagekräftigen Ordner- und Dateinamen ist man schnell am Limit)

Zielst Du da jetzt auf den Unterschied zwischen Dateinamen (welcher den gesamten Pfad beinhaltet) oder den "Pfad", der vom aktuellen "Standort" zur Zieldatei führt? Bei dem tatsächlichen Dateinamen (Zusammensetzung aller Verzeichnisse + Dateinamen) unterliegt Linux nämlich keinem Limit von 4096. Weder der Kernel noch das Dateisystem. In meinem kürzlichen Posting habe ich ja schließlich ein echtes Pfad-Monster erstellt. In diesem tiefen Ordner konnte ich ganz normal Dateien anlegen und bearbeiten. Nur der direkte Zugriff über die 4k-Grenze hinweg war nicht möglich. Details folgen...

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

Bitte sehr: Das Limit von 4096 existiert. Der verwendete Pfad darf dieses Limit nicht erreichen, sonst erhält man "File name too long". Dabei spielt es keine Rolle, ob es sich um einen absoluten oder einen relativen Pfad handelt. Beispiel: Angenommen, der Dateiname /home/user/blabla/.../.../../datei ist 4100 Zeichen lang. Die Datei kann somit nicht direkt von / erreicht werden. Der Anwender 'user' hat aber kein Problem, da seine Shell normalerweise auf /home/user "steht". Bei meinem Monster war es die Tatsache, dass ich mich immer um 100 Zeichen weitergehangelt habe, also nie Pfade hatte, die länger als 200 Zeichen waren. Der feine Unterschied liegt also in "Pfad" und "kummulierter Dateiname".

Ganz nett ist auch folgender Einzeiler, der eigentlich nur eine Datei im aktuellen Verzeichnis auszugeben versucht:

echo "huhu" > abc123; cat $(x="";for i in $(seq 2045); do x=$x"./"; done; echo $x)abc123

(mit 2044 mal "./" klappt es noch... 😉 )

Der maximal mögliche Pfad (was nicht gleich maximal möglicher Dateiname ist!) ist also 4095 (nicht 4096).

Und die Moral von der Geschicht: Mir fällt keine bessere und trotzdem kurze Formulierung ein. Ich bessere die Zahl aus und füge mich ansonsten der Mehrheit 😉

Wenn ich Dich richtig verstanden habe, liegt es also immer am derzeitigen "Standort", ob der Pfad incl. Datei 4095 Bytes lang ist:

Man befindet sich in /home/USER

• $ cat [Pfad/mit/4095/bytes/incl/Dateiname] geht (relativer Pfad)

• $ cat /home/USER/[Pfad/mit/4095/bytes/incl/Dateiname] geht nicht (absoluter Pfad)

❓

DrScott schrieb:

Zielst Du da jetzt auf den Unterschied zwischen Dateinamen (welcher den gesamten Pfad beinhaltet) oder den "Pfad", der vom aktuellen "Standort" zur Zieldatei führt?

Ja, in etwa. Unter Windows kann man keine Datei mit 255 erstellen. Es gilt die Beschränkung:

C:\ordnername\dateiname       : max Dateinamenlänge = 255 - Pfadnamenlänge 
Beispiele:
c:\dateiname                  : max Dateinamenlänge = 255 - Pfadnamenlänge  = 255 -  1    
c:\Neuer Ordner\dateiname     : max Dateinamenlänge = 255 - Pfadnamenlänge  = 255 - 13 

unter windows  c:\254     C:\99\154      C:\99\99\54
unter Linux:     /255       /255/255        /255/255/255 

Reicht es nicht zu sagen, daß die Betriebssysteme die Möglichkeiten des Dateisystems unterschiedlich nutzen. Hinsichlich Dateinamenlänge
Linux:
/ordnername/dateiname: max Dateinamenlänge = 255
Windows:
C:\ordnername\dateiname: max Dateinamenlänge = 255 - Pfadnamenlänge

Aus dieser eigenwilligen Nutzung des Dateisystems durch Windows ergibt sich: Auf c:\ kann der Dateiname maximal 254 lang sein. Erstellt man eine Datei in c:\Dokumente und Einstellungen\Administrator\Desktop\ ist die max mögliche Dateinamenlänge entprechend kürzer. Eine 254 lange Datei, die auf c:\ erstellt wurde, kann nicht auf den Desktop verschoben werden, weil sie zu lang ist.
Diese Einschränkung macht halt Linux so nicht. Das mit den 4096 würde ich gar nicht erwähnen.

kaputtnik schrieb:

Wenn ich Dich richtig verstanden habe, liegt es also immer am derzeitigen "Standort", ob der Pfad incl. Datei 4095 Bytes lang ist:

Man befindet sich in /home/USER

• $ cat [Pfad/mit/4095/bytes/incl/Dateiname] geht (relativer Pfad)

• $ cat /home/USER/[Pfad/mit/4095/bytes/incl/Dateiname] geht nicht (absoluter Pfad)

❓

Ja, ich glaube wir verstehen uns. Die Regel ist eigentlich ziemlich einfach. Zum Erreichen einer Datei darf der dafür nötige Pfad - egal ob absolut oder relativ - nicht länger als 4095 Zeichen lang sein. Falls die Datei aber "weiter entfernt" liegt, so muss man sich erstmal - nötigenfalls in mehreren Schritten - per "cd" in die Richtung hangeln...

@gabi:

Linux:
/ordnername/dateiname: max Dateinamenlänge = 255 Windows:
C:\ordnername\dateiname: max Dateinamenlänge = 255 - Pfadnamenlänge

Du willst damit sagen, dass unter Windows die Dateinamenlänge von der Pfadlänge abhängt, unter Linux aber nicht?

Habe es grad mal getestet (allerdings unter NTFS): Hier zählt das "c:" auch noch dazu.

• Unter Windows ist die Pfadlänge auf 255 Zeichen beschränkt

Dieser Satz schließt Eure Erfahrungen ja ein.

• Unter Linux ist die Pfadlänge auf 4095 Bytes beschränkt

Und dieser Satz stimmt ja auch ( wenn auch nur bei einem relativen Pfad) Edit: War unsinn!.

Es wird kaum "normale" User geben, die diese Beschränkungen jemals erreichen. Trotzdem sollten diese Dinge drinstehen! Wer will, kann ja noch erläuternde Texte dazuschreiben...

Was vllt ganz Nett wäre: Damit der Leser ein Gefühl dafür bekommt, wie lang eigentlich 255 Zeichen sind, könnte man einen Beispielpfad mit 255 Zeichen dort einstellen... ☺

/home/USER/Dies/ist/ein/Beispiel/um/die/Länge/eines/255/Zeichen/langen/Dateipfades/anschaulich/darzustellen/Um/255/Zeichen/zu/erreichen/sind/sehr/viele/Buchstaben/nötig/Jeder/mag/selbst/entscheiden/ob/er/einen/so/langen/Dateipfad/erreichen/wird/Datei.txt

Die Länge passt nicht ganz, es sind 254 Zeichen, aber der Text enthält zwei Umlaute...

habe mal den Link zu Link zu Upgrade auf ext4 unten hinzugefügt!

kaputtnik schrieb:

• Unter Windows ist die Pfadlänge auf 255 Zeichen beschränkt

Dieser Satz schließt Eure Erfahrungen ja ein.

Meine nicht. Manchmal sind es auch mehr, und machmal sind es auch weniger. Je nachdem, wie man bei der Erstellung vorgeht.

Was vllt ganz Nett wäre: Damit der Leser ein Gefühl dafür bekommt, wie lang eigentlich 255 Zeichen sind, ...

Unter Windows ist das durchaus ein bekanntes Problem, das dann entsteht, wenn man zB eine Installations-CD, die die Tiefe von 255 nahezu ausreizt, auf Festplatte kopieren will. Kopieren nach c:\ geht, kopieren nach c:\cad\softcad\softcad v2009\ geht schon nicht mehr.

gabi schrieb:

kaputtnik schrieb:

• Unter Windows ist die Pfadlänge auf 255 Zeichen beschränkt

Dieser Satz schließt Eure Erfahrungen ja ein.

Meine nicht. Manchmal sind es auch mehr, ... Aus dieser eigenwilligen Nutzung des Dateisystems durch Windows ergibt sich: Auf c:\ kann der Dateiname maximal 254 lang sein.

Hier schreibst Du selber "maximal". Und 254 = 256 minus "C:"

... und machmal sind es auch weniger. Je nachdem, wie man bei der Erstellung vorgeht.

Vllt reden wir einfach aneinander Vorbei? Ich rede von "Pfadlänge" und verstehe darunter den kompletten Pfad incl Dateiname. So stehts ja auch im Artikel.

Heute Abend fülle ich mal die zweite Tabelle...

Hallo,

erst mal schön, dass sich der Artikel so dynamisch entwickelt! 👍

Da die Hauptaufgabe des Artikels ja darin besteht, dem Benutzer die Entscheidung über das richtige Dateisystem zu erleichtern, würde ich die "Merkmale" Tabelle vor die "Generellen Informationen" setzen.

Begründung:
Die Merkmale zu vergleichen ist für jeden wichtig, die allgemeinen Informationen - wie z.B. Entwickler - finde ich zwar sehr sinnvoll, sind aber für die Entscheidung nicht so existenziell. Ich sehe die "Generellen Informationen" daher schon eher als Zusatzinformationen.

Außerdem würde ich in der Merkmale-Tabelle noch die Spalten "Rechteverwaltung" und "Journaling" aufführen und dann in der jeweiligen Dateisystem-Reihe einfach nur noch Häkchen setzen, ob das Dateisystem diese Merkmale bietet oder nicht. Bis jetzt hat man ja "nur" die unterschiedlichen Begrenzungen als Entscheidungshilfe. Das finde ich etwas zu wenig.

Viele Einsteiger dürfte es auch interessieren, ob sich das Dateisystem als "Austauschsystem" zwischen unterschiedlichen Betriebssystemen eignet. Dafür würde sich sicherlich auch eine Extra-Spalte lohnen.

Darüber hinaus teile ich kaputtnik Meinung, dass ein "Hintergrund-Artikel" zu dem Thema wünschenswert wäre.

Gruß, Martin

kaputtnik schrieb:

Es wird kaum "normale" User geben, die diese Beschränkungen jemals erreichen. Trotzdem sollten diese Dinge drinstehen!

Gut. Aber wenn es drint steht, dann sollte es korrekt drinstehen, oder? Die Begründung, kaum ein User würde diese Grenze erreichen, sollte nur darüber entscheiden, ob der Hinweis rein kommt oder nicht. Ich versuche mich jetzt doch noch mal. Was haltet ihr von:

"Unter Linux dürfen Pfadangaben nicht länger als 4095 Zeichen sein. Dennoch ist es möglich, weit tiefer verschachtelte Dateien zu erzeugen und zu nutzen, wenn die notewenigen Verzeichnisoperationen (Erstellung, Wechsel) nicht in einem einzelnen Schritt durchgeführt werden."

Unter Windows (NTFS) scheint die Sache auch nicht ganz so klar zu sein: Ich habe eine Verzeichnisstruktur

c:\[200 Zeichen]\[43 Zeichen]

angelegt. Bei den 43 Zeichen hat mich Windows schon eingeschränkt. Mehr ging für das Verzeichnis nicht. Insgesamt ist dieser Pfad 247 Zeichen lang (mit abschließendem \ 248 Zeichen). In diesem Verzeichnis kann ich keine Datei mehr anlegen, da "Windows" versucht, einen Dateinamen vorzuschalgen (z.b. "Neu Textdatei.txt"). Nur per Eingabeaufforderung kann ich hier noch was anlegen. Und nun kommt der Hammer: In der Kommandozeile habe ich unter NTFS dann in diesem Verzeichnis eine 80 Zeichen lange Datei angelegt. Macht insgesamt dann also 328 Zeichen. Mit dieser Datei kann im "Dateimanager" (heißt das Ding so?) dann aber nichts anfangen. Sie wird mit zwar angezeigt (mit allen 80 Zeichen), aber mehr geht nicht. Das Kontextmennü ist bis auf ein paar unnütze Einträge leer. Nichtmal "Eigenschaften" ist verfügbar. Löschen geht auch nicht. In der Kommandozeile kann man aber normal damit arbeiten...

Auch hier scheinen sich also Beschränkungen des Dateisystems, des Betriebsystems und sogar des verwendeten Programms zu vermischen...

kaputtnik schrieb:

Vllt reden wir einfach aneinander Vorbei? Ich rede von "Pfadlänge" und verstehe darunter den kompletten Pfad incl Dateiname. So stehts ja auch im Artikel.

Nee, ich habe nur den . hinter dem, was ich gestern dachte, heute durch drei ? ersetzt.
Man kann durch Verschieben von Dateien oder Ordnern überlange Dateipfade erzeugen. Und manchmal sitzt die Schranke tiefer. Beispiele:

c:\[Datei 254 Zeichen]                             ### max Länge durch Erstellen
c:\[Ordner 242 Zeichen]                            ### max Länge durch Erstellen, kein Erstellen in [Ordner 242 Zeichen] möglich.  
c:\[Ordner 242 Zeichen]\[Datei 13 Zeichen]  = 256  ### [Datei 13 Zeichen] durch Verschieben. Kein Zugriff auf [Datei 13 Zeichen].
c:\[Ordner 242 Zeichen]\[Datei 12 Zeichen]  = 255  ### [Datei 12 Zeichen] durch Verschieben. Zugriff auf [Datei 12 Zeichen] möglich.
c:\[Ordner 235 Zeichen]\[Neu Textdatei.txt] = 253  ### [Ordner 235 Zeichen] ist gerade kurz genug, um "Neu Textdatei.txt" zu erstellen.
c:\[Ordner 235 Zeichen]\[Datei 19 Zeichen]  = 255  ### "Neu Textdatei.txt" läßt sich um 2 Zeichen vergrößern.

(ich zähle jeweils ohne "c:\", aber mit allen "\" hinter den Dateiordnern.) w2k und ntfs.

Gut. hab mal wieder n bisschen überarbeitet: http://wiki.ubuntuusers.de/Baustelle/Dateisystem?action=diff&new_rev=138057&rev=137790

Anstatt auf die Diskussion zu verweisen, wäre es natürlich besser, auf einen entsprechenden Abschnitt im Hintergrundartikel zu verweisen... 😀

Ich finde, das man da in diesem Artikel nicht genauer drauf eingehen sollte.

Newubunti schrieb:

Da die Hauptaufgabe des Artikels ja darin besteht, dem Benutzer die Entscheidung über das richtige Dateisystem zu erleichtern, würde ich die "Merkmale" Tabelle vor die "Generellen Informationen" setzen.

Ja, das sollte man machen.

Außerdem würde ich in der Merkmale-Tabelle noch die Spalten "Rechteverwaltung" und "Journaling" aufführen [...]

Es kommt ja noch eine Tabelle. Ob Journaling da reingehört? Hmmm... Ja!

Viele Einsteiger dürfte es auch interessieren, ob sich das Dateisystem als "Austauschsystem" zwischen unterschiedlichen Betriebssystemen eignet. Dafür würde sich sicherlich auch eine Extra-Spalte lohnen.

Eine Extraspalte wäre IMHO zu viel. Das gibt zu wenig her. Es ist ein Artikel der die Dateisysteme beschreibt. Welche Dateisysteme zum Datenaustausch in Frage kommen, wird bei Partitionierungsfragen im Forum doch jedesmal angegeben. Muss das dann hier auch nochmal in ne extra Spalte? Evtll wäre am Ende noch ein Absatz "Tipps fürs richtige Dateisystem" oder so angebracht in der man das schreiben kann.

Darüber hinaus teile ich kaputtnik Meinung, dass ein "Hintergrund-Artikel" zu dem Thema wünschenswert wäre.

Gell? 😉 Wobei ich befürchte, das wir uns hier falsch verstehen. Ich meine, das in so einem Hintergrundartikel keine technischen Zusammenhänge erklärt werden sollten, sondern vielmehr erläuternde Texte, Beispiele (Datei- und Pfadlängen) und Befehle (dumpe2fs -h, parted -print) enthalten sollte. Sozusagen die Theorie des Artikels mit Beispielen erläutern.

kaputtnik schrieb:

Darüber hinaus teile ich kaputtnik Meinung, dass ein "Hintergrund-Artikel" zu dem Thema wünschenswert wäre.

Gell? 😉 Wobei ich befürchte, das wir uns hier falsch verstehen. Ich meine, das in so einem Hintergrundartikel keine technischen Zusammenhänge erklärt werden sollten, sondern vielmehr erläuternde Texte, Beispiele (Datei- und Pfadlängen) und Befehle (dumpe2fs -h, parted -print) enthalten sollte. Sozusagen die Theorie des Artikels mit Beispielen erläutern.

... und dann bitte von Datenverwaltung dorthin verlinken!

BG S*

kaputtnik schrieb:

Newubunti schrieb:

Da die Hauptaufgabe des Artikels ja darin besteht, dem Benutzer die Entscheidung über das richtige Dateisystem zu erleichtern, würde ich die "Merkmale" Tabelle vor die "Generellen Informationen" setzen.

Ja, das sollte man machen.

Außerdem würde ich in der Merkmale-Tabelle noch die Spalten "Rechteverwaltung" und "Journaling" aufführen [...]

Es kommt ja noch eine Tabelle. Ob Journaling da reingehört? Hmmm... Ja!

Ah, wusste ich nicht. OK.

Viele Einsteiger dürfte es auch interessieren, ob sich das Dateisystem als "Austauschsystem" zwischen unterschiedlichen Betriebssystemen eignet. Dafür würde sich sicherlich auch eine Extra-Spalte lohnen.

Eine Extraspalte wäre IMHO zu viel. Das gibt zu wenig her. Es ist ein Artikel der die Dateisysteme beschreibt.

Ich würde eher sagen, der Artikel skizziert die Dateisysteme. Richtig beschreiben - zumnindest dann die Linux relevanten - würde dann ein Hintergrundartikel.

Welche Dateisysteme zum Datenaustausch in Frage kommen, wird bei Partitionierungsfragen im Forum doch jedesmal angegeben. Muss das dann hier auch nochmal in ne extra Spalte?

Ich finde ja, weil es hier ja um Dateisysteme geht und vor allem weil der Artikel ja auch als Entscheidungshilfe gedacht ist. Ich finde es hier thematisch angebrachter als in den Partitionierungsartikeln. Mit Partitionierung hat es ja an sich nichts zu tun.

Evtll wäre am Ende noch ein Absatz "Tipps fürs richtige Dateisystem" oder so angebracht in der man das schreiben kann.

Dann muss man aber wieder hin und her scrollen. Da hier die Entscheidungshilfe im Vordergrund steht, sollten alle Kriterien, die für die Entscheidung relevant sind in die Tabelle, damit es schön übersichtlich gegenübergestellt ist. OK... ich gebe natürlich zu, dass die Seitenbreite da ein gewisse Limitierung darstellt.

Darüber hinaus teile ich kaputtnik Meinung, dass ein "Hintergrund-Artikel" zu dem Thema wünschenswert wäre.

Gell? 😉 Wobei ich befürchte, das wir uns hier falsch verstehen. Ich meine, das in so einem Hintergrundartikel keine technischen Zusammenhänge erklärt werden sollten, sondern vielmehr erläuternde Texte, Beispiele (Datei- und Pfadlängen) und Befehle (dumpe2fs -h, parted -print) enthalten sollte. Sozusagen die Theorie des Artikels mit Beispielen erläutern.

Naja, wir verstehen uns insoweit richtig, als dass dieser Artikel nur eine Skizzierung zwecks Entscheidungshilfe darstellt. ☺

Bei Hintergrundwissen würde ich allerdings teilweise etwas anderes vermitteln, als Du. Ich würde mir da so eine Art Schnittmenge zwischen diesem Artikel und den Wikipedia-Artikeln zu den einzelnen Dateisystemen wünschen.

Befehle gehören nach meiner Meinung nicht in einen Artikel über Dateisysteme - oder nur sehr, sehr beschränkt, weil ein Dateisystem ja keine Befehle mitbringt. Für Befehle würde ich einen Artikel "Dateisystem-Operationen" machen - sofern es den nicht schon gibt.

Für mich gehört in einen Hintergrundartikel über Dateisysteme mindestens die grobe Skizzierung der Struktur. Also so etwas, wie welche Organisationsblöcke gibt es, wo liegen diese auf der Partition etc..

Begründung:
Nehmen wir mal an Du schreibst einen Artikel über Datenrettung. Um Daten zu retten - also für den Fall dass es nicht vollautomatisch geht - ist die Kenntnis des ursprünglichen Dateisystems von Vorteil. In den Artikel Datenrettung würde die Erklärung der einzelnen Dateisysteme aber nicht gehören. Das würde den Artikel sprengen.

Also müsste er auf einen Artikel über Dateisysteme zurückgreifen. Der richtige Artikel wäre m.E. dafür "Grundlagen Dateisysteme". Dieser Artikel wäre aber mit der groben Erklärung der Linux relevanten Dateisystem-Strukturen mehr als ausgelastet. Für Erklärung von Befehlen wäre da kein Platz mehr.

Gruß, Martin