Kann überlanger Dateiname (scheinbar) "Speicherplatz" belegen?

[FatManStanding]

Hallo,

ich habe auf meinem Raspberry Pi mittels wget ein Video heruntergeladen und vergessen einen brauchbaren Dateinamen zu vergeben. wget nimmt dann die URL als Dateinamen an. Der DL brach nach 3,3GB ab da angeblich kein Speicherplatz mehr verfügbar sei. Hab die Datei auf meinen Rechner verschoben und jetzt sind wieder 21GB frei. Kann es an diesem überlangen Dateinamen gelegen haben? Die URL habe ich nicht mehr da es ein Video von Facebook war das nicht direkt geladen werden kann. Ich muss das erst über einen Online-FB-Downloader in eine ladebare URL umwandeln lassen. Die ist da jedesmal anders - zumindest ist eine Wiederaufnahme eines abgebrochenen DLs nicht möglich.

 

[JumpingCat]

Ein Dateiname verbraucht keinen Speicherplatz.

 

[foofoobar]

$ grep PATH_MAX /usr/include/linux/limits.h
#define PATH_MAX        4096    /* # chars in a path name including nul */
$

Ergänzung (29. August 2024)

Ein Dateiname verbraucht keinen Speicherplatz.

Falsch:

$ ls -ld .
drwxrwxr-x 2 xx xx 4096 Aug 29 22:53 .
$ for i in $(seq 0 2000)
> do
> touch ${i}hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh
> done
$ ls -ld .
drwxrwxr-x 2 xx xx 499712 Aug 29 22:55 .
$

-----------------------------------------------------------------------------------------------------------------

$ ls -ld .
drwxrwxr-x 2 xx xx 4096 Aug 29 22:59 .
$ for i in $(seq 0 2000); do touch ${i}h; done
$ ls -ld .
drwxrwxr-x 2 xx xx 36864 Aug 29 22:59 .
$

 

[kieleich]

Dateinamen verbrauchen Speicherplatz, irgendwo müssen diese Namen ja auch gespeichert werden. Zum Beispiel im Verzeichnis also man könnte das Verzeichnis verstehen als Datei die alle Dateinamen enthält. Na ja ist Dateisystem abhängig wie das implementiert ist. Wenn der Dateiname "kein Speicherplatz verbraucht" dann weil der von Anfang an schon reserviert wurde ...

Bei Linux Dateisystem ist es theoretisch möglich wenn man Millionen Dateien in ein Verzeichnis schmeisst (das Verzeichnis wird entsprechend groß um Millionen Datei Namen zu speichern) und dann löscht man die Dateien wieder aber das Verzeichnis wird, davon nicht kleiner. Wenn der Dateisystem Designer sich gedacht hat, wo mal so viele Dateien drin waren kommen irgendwann auch wieder so viele dazu also warum kleiner machen

Also wenn man ein uuur altes Dateisystem kopiert kanns schon mal vor kommen das die Kopie mysteriös kleiner ausfällt als das Original weil Altlasten wie so gewachsene Verzeichnisse eben nicht mit ge schleppt werden

Gigabytes kommen da aber normalerweise nicht bei rum. Das wäre ein extremer Sonderfall

 

[Sebbi]

Der DL brach nach 3,3GB ab da angeblich kein Speicherplatz mehr verfügbar sei. Hab die Datei auf meinen Rechner verschoben und jetzt sind wieder 21GB frei. Kann es an diesem überlangen Dateinamen gelegen haben?

Dann wurde der Speicherplatz schon vorher "weich" reserviert. Als der Abbruch kam, wurde dann dieser wohl nicht wieder freigegeben und die Datei war real 3,3 GB groß, in der Allocation Table aber 21 GB. Durch das verschieben wurden dann die 21 GB freigegeben, weil die Datei dann gelöscht wird und auf deinen Rechner mit den realen Größenangaben geschrieben.

 

[madmax2010]

Ein Dateiname verbraucht keinen Speicherplatz.

Je nach Dateisystem im meist um die 255 Byte. Kommt halt drauf an wie und wo er dann "abgelegt"wird.

Wobei man sich hier mehr sorgen um die FAT, inodes oder ähnliches machen sollte.

@FatManStanding war in dem Directory noch Platz?

 

[foofoobar]

Je nach Dateisystem im meist um die 255 Byte. Kommt halt drauf an wie und wo er dann "abgelegt"wird.

Hmm, ein paar Postings drüber habe ich doch aufgezeigt das unterschiedlich lange Filenamen unterschiedlich viel Platz benötigen.

 

[Uridium]

@foofoobar:
Welches Dateisystem war das denn? ext4?
Ist das bei b-tree basierten auch (btrfs, bcachefs, etc)?

 

[foofoobar]

Welches Dateisystem war das denn? ext4?

Ach, habe ich vergessen mit anzugeben, ext4 als default ist zwischen meinen Ohren fest verdrahtet.

Ist das bei b-tree basierten auch (btrfs, bcachefs, etc)?

Ist wahrscheinlich da auch so, dieses Verhalten bekommt man sicherlich for free wenn man b-trees für unterschiedlich grosse Objekte effizient implementiert.

 

[Uridium]

$ grep PATH_MAX /usr/include/linux/limits.h
#define PATH_MAX        4096    /* # chars in a path name including nul */

Das ist wahrscheinlich nur ein internes (dateisystemunabhängiges) Hardlimit.

ext4 hat wohl 255 Zeichen, bcachefs knapp 2000 512 und NTFS 32768 auch 255.
https://www.reddit.com/r/bcachefs/comments/uv3ip1/what_is_the_max_filename_length_on_bcachefs/

Wenn man bedenkt, dass UTF auch mal 2 oder mehr Bytes pro Zeichen benötigen kann, ist das bei ext4 gar nicht so viel.

 

[foofoobar]

ext4 hat wohl 255 Zeichen, bcachefs knapp 2000 und NTFS 32768.
https://www.reddit.com/r/bcachefs/comments/uv3ip1/what_is_the_max_filename_length_on_bcachefs/

Dann sollte man mal ein NTFS-FS mit 30k grossen Filenamen unter Linux mounten und schauen was passiert.
Das könnte exploit fähig sein.

 

[Uridium]

Ich habe das mal getestet. Hauen mich jetzt nicht um die Werte.
ext4 = 255 Zeichen
bcachefs = 512 Zeichen
btrfs = 255 Zeichen
ntfs (ntfs3 und ntfs-3g) = 255 Zeichen
exfat (kernel) = 255 Zeichen

#!/bin/bash

set -e
err_report() {
    echo "Dateilänge $1 ungültig!"
}
trap 'err_report $i' ERR

start=250
end=260
# leading counter is padded to 5 chars (e.g. 00255aaaaaaa...)
[[ "${start}" -lt "6" ]] && exit 1
[[ "${start}" -gt "${end}" ]] && exit 2
for ((i=start; i<=end; i++)); do
    touch "$(printf "%05d" ${i})$(head -c $((${i}-5)) /dev/zero | tr '\0' 'a')"
done

$ create_long_filenames.sh 
touch: '00256aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' kann nicht berührt werden: Der Dateiname ist zu lang
Dateilänge 256 ungültig!

$ create_long_filenames.sh 
touch: '00513aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' kann nicht berührt werden: Der Dateiname ist zu lang
Dateilänge 513 ungültig!

 

[nutrix]

NTFS geht länger:
https://learn.microsoft.com/de-de/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

 

[Uridium]

Das bezieht sich aber auf die gesamte Pfadlänge, nicht Dateinamen. Diese können mit Unicodegeblubber aber durchaus länger (als 255) sein, erstaunlicherweise auch unter Linux/NTFS3.
https://learn.microsoft.com/en-us/w...onality-comparison?redirectedfrom=MSDN#limits
https://unix.stackexchange.com/a/619635/102276

Neben Reiser (deprecated), HAMMER (BSD) und NTFS bleibt dann (laut Wikipedia) nur noch bcachefs übrig. Ein vielleicht nicht unerhebliches Alleinstellungsmerkmal.

Edit:
Das mit dem 462 Bytes Filename funktioniert tatsächlich unter NTFS3. Netter Kopierschutz.

name="和総坂裁精座回資国定裁出観産大掲記労。基利婚岡第員連聞余枚転屋内分。妹販得野取戦名力共重懲好海。要中心和権瓦教雪外間代円題気変知。貴金長情質思毎標豊装欺期権自馬。訓発宮汚祈子報議広組歴職囲世階沙飲。賞携映麻署来掲給見囲優治落取池塚賀残除捜。三売師定短部北自景訴層海全子相表。著漫寺対表前始稿殺法際込五新店広。"
touch "$name"

 

[foofoobar]

start=250
end=260
# leading counter is padded to 5 chars (e.g. 00255aaaaaaa...)
[[ "${start}" -lt "6" ]] && exit 1
[[ "${start}" -gt "${end}" ]] && exit 2

Wann sollen diese Bedingungen vor den exits eigentlich zutreffen?

BTW, kürzer und IMHO übersichtlicher:

$ a='a'; while touch $a ; do rm $a; a=${a}a; done; echo $((${#a} - 1))
touch: cannot touch 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa': File name too long
255
$

 

[Uridium]

Wann sollen diese Bedingungen vor den exits eigentlich zutreffen?

Wenn man start= und end= falsch gesetzt hat.

BTW, kürzer und IMHO übersichtlicher:

Ja, fängt aber immer bei 1 an.

Ich wollte anfangs einen /dev/urandom string tr -dc A-Za-z0-9 </dev/urandom | head -c 16; echo). Die waren unsortiert, also einen leading counter dazu gebastelt. Dann fiel mir auf, dass das mit einem single char eigentlich einfacher geht. Da war ich aber schon fertig und hab beides einfach kombiniert. Letztlich wollte ich die längste Datei mit 'ls' sehen (als letzte Datei unten).