Begrenzung der Dateinamenlänge in Bash


76

Die folgenden Fragen sind nur für Bash und Linux gedacht:

  1. Gibt es eine Begrenzung für die Anzahl der Zeichen im absoluten Pfadnamen einer Datei?
  2. Gibt es eine Begrenzung für die Anzahl der Zeichen nur für den Dateinamen (ohne Erweiterung)?

Wenn ja, wie hoch könnten diese Grenzen sein? Wie kann ich auf sie zugreifen, wenn sie systemspezifisch sind?


6
Ich habe mich immer gefragt, wie Leute Grenzen wie die Länge von Dateinamen erreichen können. Was tust du?
Karoly Horvath

@yi_H: LOL! nichts, nur einen großen Dateinamen (absoluter Pfad) in eine Datei schreiben und den Namen daraus lesen. Das Lesen erfolgt mit einem Sternchen, und ich muss herausfinden, wie viele Zeichen ich lesen muss. Diese Frage tauchte nebenbei auf.
Sriram

1
Das riecht so sehr nach Hausaufgaben ... aber am Ende gehört es zu ServerFault, SuperUser oder Unix & Linux.
Bobby

1
@ Bobby: Wenn es Hausaufgaben wären, hätte ich es so beschriftet.
Sriram

1
@ Bobby: Keine Sorge, ich habe deinen Kommentar nicht als Beleidigung oder ähnliches verstanden. Prost!
Sriram

Antworten:


71

Es hängt sehr stark vom Dateisystem ab. Für den ext FS (derzeit am häufigsten unter Linux verwendet):

  • Maximale Dateinamenlänge: 255 Byte
  • maximale Pfadlänge: keine

Die Erweiterung ist dem FS nicht bekannt, sie umfasst 255 Byte, einschließlich der Erweiterung (Sie können Dateinamen ohne Erweiterungen verwenden).

Hier ist eine ausführlichere Liste dieser Grenzwerte pro FS.

Es kann auch Erweiterungen für Ihr Dateisystem geben, die auch Ihre maximale Länge ändern können. Zum Beispiel eCryptFS, das einen Teil des unteren Dateinamens verwendet, um Metadaten zu speichern, und den Dateinamen auf eine maximale Länge von 143 Zeichen begrenzt. Siehe Ubuntu eCryptFS-Launchpad- Eintrag.


7
Es gibt auch das in Linux / Limits.h definierte Limit PATH_MAX für den Linux-Kernel , das normalerweise 4096 Zeichen beträgt. Das letzte Zeichen ist für das Nullzeichen des Zeichenfolgenabschlusses reserviert.
BeowulfNode42

Außerdem kann jede Anwendung ihre eigene Grenze haben, die sie auferlegt.
BeowulfNode42

Falls jemand irgendwelche Zweifel hat: Wenn ich diese Antwort mit dieser auf a kombiniere ecryptfs, konnte ich überprüfen, ob der Fehler immer noch ungelöst ist (obwohl ich beim Lesen des Fehlers selbst denke, dass er niemals behoben wird)
ThanksForAllTheFish

38

Führen Sie in einem temporären Verzeichnis Folgendes aus:

num=1
while [ true ]
do 
   if ! touch $(printf "%${num}s"  | tr ' ' 'a')
   then
       echo $num
       break
   fi
   ((num++))
done

und ich bekomme:

touch: cannot touch `aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa': File name too long
256

was bedeutet, dass mein Limit 255 ist.


1
Ich bekomme 144, was bedeutet, dass mein Limit 143 ist. Warum so kurz!? Ich verwende Ubuntu 16.04 LTS 64-Bit.
Gabriel Staples

eCryptFS verwendet einen Teil des Dateinamens für Metadaten.
Andrew Beals

15

Unter Mac OS X 10.6.7:

man getconf
getconf NAME_MAX /   # 255 bytes
getconf PATH_MAX /   # 1024 bytes

# check file path length with wc before using touch, mkdir, etc.
echo '/very/lllooooonnnnnggggg/file/path.txt' | wc -c

10

Ich verweise auf andere Antworten, bitte stimmen Sie ihnen zu.

Unter Linux hängt die Länge von Dateinamen und Pfadnamen ab von:

Um diese Eigenschaften dynamisch zu erhalten ::

  • Erstellen Sie einen Dateinamen (oder Pfadnamen) immer länger, wie von dogbane erklärt
  • Verwenden Sie den getconfvon tim vorgeschlagenen Befehl , der auch unter Linux verfügbar ist:

    $ getconf NAME_MAX /mnt/sda2/
    255
    $ getconf PATH_MAX /mnt/sda3/
    4096
    

8

Die Single UNIX-Spezifikation erwähnt NAME_MAXund PATH_MAXKonstanten in limit.h , die mit pathconf gelesen werden können . Dies ist jedoch sehr dateisystemabhängig, und es ist unwahrscheinlich, dass Sie eine solche Grenze erreichen.

HINWEIS: Als Programmierer sollten Sie diese Grenzwerte nicht fest codieren. Sie sollten die dynamische Zuordnung verwenden, damit sie immer funktioniert, solange das zugrunde liegende System alles zulässt, was Sie tun.


4
  1. Gibt es eine Begrenzung für die Anzahl der Zeichen im absoluten Pfadnamen einer Datei?

Ja da ist.

Siehe Antwort von sfp unter der Frage Dateinamenlängenbeschränkungen unter Linux? bei Serverfehler

Zusamenfassend:

#define PATH_MAX        4096    /* # chars in a path name including nul */

Und für:

  1. Gibt es eine Begrenzung für die Anzahl der Zeichen nur für den Dateinamen (ohne Erweiterung)?

in der gleichen verknüpften Antwort:

#define NAME_MAX         255    /* # chars in a file name */

1
Vielen Dank für den Link zu der ähnlichen Frage zu Serverfault. Aber ich denke nicht, dass die Antwort von sft ziemlich gut ist. Ich bevorzuge die Antwort von @WerkkreW mit einem guten Link: en.wikipedia.org/wiki/Comparison_of_file_systems#Limits
oHo

1
Bei diesem Link handelt es sich um Dateisysteme, nicht um Bash oder Linux, wie in der Frage angegeben. Beispielsweise wird kein für das ext3-Dateisystem definiertes Limit aufgeführt, für Linux gilt jedoch ein Limit von 4096 (unabhängig vom Dateisystem).
David Balažic

1
Ich stimme dir zu :-) Danke, dass du auf eine ähnliche Frage hingewiesen hast +1 :-) Nehmen wir an, es hängt von beiden ab: FS und linux/limits.h. Aber die ultimative Antwort wäre so etwas wie cat /proc/sys/fs/file-maxoder ... getconf NAME_MAX /... Ja, der letzte Befehl ist der gute ... und Tim, wie er vor mir gefunden wurde. Prost
oHo


2

Dies ist nicht bash-abhängig; Es ist vom Betriebssystem abhängig. Auf einem Mac ist es 0xff für einen Dateinamen und 0x400 für einen Pfadnamen. Ubuntu 9 hatte ein Limit von 144 Zeichen für Dateinamen.

Ich habe diesen Link in Wikipedia gefunden . Hier werden Pfad- und Dateinamenbeschränkungen für zahlreiche Dateisysteme angegeben.


Auf dem beteiligten Mac befindet sich HFS + und der Unix-Computer ist ext4.
ncmathsadist

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.