Da dieses Thema immer wieder hochkommt habe ich mir das jetzt mal etwas genauer angeschaut. Dabei sind mir einige Ungereimtheiten aufgefallen, die ich hier mal zur Diskussion stellen möchte. Wenn im Folgenden Puffergrößen bzw. Stringlängen genannt werden, so sind diese immer inclusive der abschließenden 0 zu verstehen.
Zunächst mal die Fakten:
- MAX_SUBTITLE_LENGTH wird in recording.c verwendet, und zwar als Anzahl der Bytes, die der "Subtitle" maximal lang sein darf. Ist er länger, werden so viele UTF-8 Symbole genommen, wie in MAX_SUBTITLE_LENGTH reinpassen.
Der "Title" wird hier nicht entsprechend behandelt (obwohl der ja auch länger sein könnte), und es wird auch nicht berücksichtigt, daß über das TITLE und EPISODE Macro ein Name wie "TITLE-EPISODE" gebaut werden könnte, der wiederum länger als MAX_SUBTITLE_LENGTH sein könnte.
- VFAT_MAX_FILENAME wird in timers.c verwendet, und zwar als Anzahl der UTF-8 Symbole, die der Filename maximal lang sein darf (wobei in cTimer::Parse() nur der Teil nach dem letzten FOLDERDELIMCHAR berücksichtigt wird, falls vorhanden, ansonsten der ganze Filename).
- Die maximale Länge (in Byte) eines Filenamens in einem Timer ist MaxFileName (256).
- An anderen Sellen benutzt VDR PATH_MAX bzw. NAME_MAX.
Wie schon von so manchem richtig angemerkt wurde, ist das ein ziemliches Durcheinander. Da wird einmal die Anzahl der Bytes benutzt, ein anderes mal die Anzahl der UTF-8 Symbole. Mal wird der ganze Filename limitiert, dann wieder nur ein Teil davon. Und schließlich wird mit zwei verschiedenen Macros gearbeitet, die aber den gleichen Wert haben.
Fragt sich also, wie man das in den Griff bekommen kann.
Hier mal ein paar Überlegungen zu möglichen Änderungen:
- Die Gesamtlänge eines Filenamens in einem Timer wird dynamisch gehandhabt, und es wird darauf geachtet, daß ein einzelner Namensbestandteil nicht größer als NAME_MAX wird (unabhängig von VFAT oder nicht).
- Unter Linux ist NAME_MAX 255 und PATH_MAX 4096, somit sollte es also in der Praxis keine Probleme geben.
- Der "name" sowie der "text" eines SI::ShortEventDescriptor können jeweils maximal 256 (255?) Byte lang sein, somit ist bei der Verwendung dieser Strings auf einem reinen Linux-System keine Spezialbehandlung erforderlich, es sei denn, sie werden über das TITLE bzw. EPISODE Macro zusammengebaut oder mit anderen Strings kombiniert.
- Unter Windows (VFAT?) ist anscheinend die maximale Länge des gesamten Pfadnamens (also Directories plus Filename) auf 255 Zeichen beschränkt. Zumindest hat das ein Versuch auf meinem Laptop mit Windows XP ergeben. Laut http://en.wikipedia.org/wiki/Long_filename sind das 255 UTF-16 Zeichen, daher wohl auch die Berechnung mit UTF-8 Symbolen anstatt Bytes in timers.c.
Schlußfolgerungen:
- Die Sonderbehandlung für den VFAT-Fall an den Stellen, wo VFAT_MAX_FILENAME verwendet wird, entfällt bzw. wird allgemein auf NAME_MAX begrenzt.
- Falls die --vfat Option eingeschaltet ist, werden Filenamen in cRecording::cRecording(cTimer *Timer, const cEvent *Event) (und nur dort!) so verkürzt, daß sie den VFAT-Bedingungen entsprechen.
Die VFAT-Namensverkürzung folgt diesen Regeln:
- Ein Pfadname für eine an einer Aufzeichnung beteiligte Datei ist folgendermaßen aufgebaut:
/videodir/folder.../name/YYYY-MM-DD.hh.mm.channel-instance.rec/00001.ts
wobei die *.ts-Dateien mit 8 Zeichen die längsten Namen haben.
- Der Teil ab YYYY wird automatisch generiert und verletzt mit Sicherheit nicht die 255er Grenze.
- Der Teil /videodir/ ist nur auf dem Linux-System sichtbar, unter Windows kann dieses Verzeichnis
vollkommen anders heißen, ja es könnte sogar ein sehr langer Pfad sein, was allerdings äußerst
ungeschickt wäre. Daher gehen wir der Einfachheit halber mal davon aus, daß der Name des
Verzeichnisses unter Windows zumindest nicht länger sein wird als unter Linux.
- Die Gesamtlänge des Pfadnamens darf bei VFAT 255 Zeichen nicht überschreiten. Ist sie größer als 255,
so wird zunächst der Anteil "name" so lange verkürzt, bis die Bedingung erfüllt ist, oder nur noch ein Zeichen
übrig ist.
- Reicht die Verkürzung von "name" nicht aus, so werden schrittweise alle "folder" von rechts nach links
ebenso behandelt. Der "/videodir"-Teil bleibt aber unverändert.
- Reicht selbst die Verkürzung aller zwischengeschalteter Directories nicht aus, so werden von rechts nach
links so lange Directories entfernt, bis die Gesamtlänge 255 Zeichen nicht mehr übersteigt. Dieser Fall dürfte
allerdings in der Praxis kaum auftreten, dann dazu müsste jemand schon mehr als 100 Unterverzeichnisse
haben - wer macht das schon...
Ich bitte um sachliche Kommentare bzw. Meinungen hierzu.
Vielleicht hat ja auch jemand eine viel bessere Idee, wie man das handhaben sollte.
Sobald aber dieser Thread (wie leider so viele in letzter Zeit) in saudumme Bemerkungen oder persönliche Angriffe abgleitet, bin ich sofort raus hier und es bleibt für die Version 2.0 alles so, wie es jetzt ist. Also bitte Gehirn einschalten vor dem Schreiben ;-).
Klaus
Das schließt den Laufwerksnamen (x:\) bzw. Freigabenamen (\\server\freigabe\) und das NUL am Ende mit ein. Was tatsächlich übrig bleibt, ist also vom Einzelfall abhängig und lässt sich nur schwer vorhersagen.
