Dateinamenlänge

[sk_akbe]

Die Länge von Dateinamen (incl. Pfad) ist ja begrenzt (mehr oder weniger je nach Dateisystem). Einige User hier benutzen leider recht lange Dateinamen (bei PDFs die Titel der Artikel u.a. Unsinn), was man in einer Multiuserumgebung ja auch nie ausschließen kann. Bisher hat der WHS da aber nicht gemeckert. Nun aber bei der Sicherung des WHS (Serversicherung, also die Shares, über Konsole auf externe USB-Festplatte) meckert das Backupmodul, daß es einige Dateien nicht sichern kann wegen zu lange Dateinamen. Hat dieses Backupmodul noch eine interne/andere Begrenzung als die in Windows übliche für NTFS-Partitionen? Auch die USB-Festplatte ist mit NTFS formatiert (das hat der WHS zwangsweise automatisch gemacht beim Einrichten als Serverfestplatte).

[Nobby1805]

m.E. sind das die normalen Windows Grenzen

Wikipedia sagt dazu: http://de.wikipedia.org/wiki/Dateiname

Dateisysteme
Dateisystem max. Anzahl Zeichen in einem Namen
NTFS 259 + 247 für den Pfad (theoretisch 32767)

Da der Pfad auf der Sicherungsplatte zusätzlich das Sicherungsdatum enthält gib es dort bei Ausnutzung der Länge im Share ein Problem

[sk_akbe]

Da der Pfad auf der Sicherungsplatte zusätzlich das Sicherungsdatum enthält gib es dort bei Ausnutzung der Länge im Share ein Problem

Das hatte ich zwar nicht bedacht, aber da kommen lediglich 16 Zeichen hinzu. Habe mal die Zeichen zählen lassen: der beanstandete Pfad hatte nur 171 Zeichen (incl. Punkten, Backslash und Leerzeichen) und der Dateiname nur 79 Zeichen. Hätte also kein Problem sein dürfen?

Den Wikipedia-Artikel kannte ich schon, aber die Frage ist, welche der dort angegebenen Grenzen für das Backup nun gilt.
Laut Fehlermeldung des WHS-Backuptools 248 für Pfad und 260 für Dateiname. Selbst wenn man die 16 Zeichen für das Sicherungsdatum zum Pfad dazuzählt, bleibt man immer noch weit unter der Grenze.

In der Summe (also Pfad + Dateiname) wären das 251 Zeichen. Zählt man hier die 16 Zeichen Sicherungsdatum hinzu, kommt man auf 267 Zeichen. Für FAT, VFAT und UDF wäre das zuviel (Grenze Pfad+Dateiname = 255 Zeichen), aber die Festplatte wurde von WHS-Backuptool zwangsweise mit NTFS neu formatiert beim Einrichten als Sicherungsfestplatte.

Hat da jemand eine Erklärung?

PS: Pfadlänge und Dateinamen lassen sich nicht ändern, weil die automatisch von der Literaturverwaltungssoftware Endnote so angelegt werden beim Einbinden von PDFs (Titel des Artikels, welcher ja manchmal sehr lang sein kann).

[OlafE]

Die Grenze von 260 Zeichen ist nicht von NTFS herruehrend, aber einige wesentliche Systembibliotheken in Windows weisen diese auf, solche, auf die beispielsweise der Explorer zugreift. Einige 3rd Party-Anwendungen machen sich darueber keine Waffel - ich habe mal erlebt, dass ich mit einer frueheren Version von Backup Exec ein Restore fahren konnte, welches solche zu tiefen Pfade erst erzeugte.
Bei jeder neuen Betriebssystembeta der letzten Jahre wurde ich mit meinen diesbezueglichen Aenderungswuenschen abgeschmettert, weil eine solche Aenderung wohl ziemlich weitreichende Folgen hat.

Wenn das Problem daher ruehrt, dass eine Drittanbieteranwendung sich nicht an die Windows Quasi-Standards haelt, sollte man mit dem Anbieter Kontakt aufnehmen und ihn darauf hinweisen.
Viele Gruesse
Olaf

[Nobby1805]

Wenn das Problem daher ruehrt, dass eine Drittanbieteranwendung sich nicht an die Windows Quasi-Standards haelt, sollte man mit dem Anbieter Kontakt aufnehmen und ihn darauf hinweisen.

In diesem Fall geht es aber doch um eine Microsoft-"Anwendung" ... die eingebaute Share-Sicherung des WHS

[OlafE]

In diesem Fall geht es aber doch um eine Microsoft-"Anwendung" ... die eingebaute Share-Sicherung des WHS

die auf den normalen Microsoft-Systemdateien aufbaut, in denen diese Begrenzung existiert ...
Und Deine Literaturverwaltung haelt sich hier entweder nicht an die Konventionen, oder Du arbeitest ueber ein Netzwerklaufwerk (bei Direktzugriff auf \\server\Benutzer\benutzername ist der Pfad nur bei einem sehr kurzen Servernamen kürzer als lokal auf dem Server, wo er ja mit d:\shares\Benutzer beginnen wuerde), wodurch sich der Pfad aus Sicht der Anwendung um einige Zeichen verkuerzen koennte, so dass die Grenze au deren Sicht noch nicht ueberschritten wurde.
In jedem Fall eine bekannte Schwaeche von Windows, um die es so keinen Workaround gibt.
Viele Gruesse
Olaf

[Nobby1805]

@Olaf:
vergiss die Literaturverwaltung, die hat damit nix zu tun ... das ist ein hausgemachtes Microsoftproblem


Erzeuge mit dem Explorer eine Datei mit maximal langem Dateinamen und mach dann eine Share-Sicherung

Datei Software\Scan\0,229xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.txt konnte nicht verarbeitet werden: Der angegebene Pfad und/oder Dateiname ist zu lang. Der vollständig qualifizierte Dateiname muss kürzer als 260 Zeichen und der Pfadname kürzer als 248 Zeichen sein.

Die Fehlermeldung passt nicht ! Der Name ist kürzer als 260 Zeichen und der Pfad ist recht kurz, sogar Name+Pfad sind kürzer als 260 Zeichen

PS 219-Zeichen Dateiname klappt noch, ab 220 kommt die Fehlermeldung

[OlafE]

Rein spekulative Vermutung - möglicherweise spielt hier noch die Tatsache herein, dass es sich in D:\shares nicht um den realen Pfad zur Datei handelt, sondern um einen Tombstone.
Ich könnte mir vorstellen, dass diese Information auch noch einige Zeichen für sich verbraucht.
Viele Grüße
Olaf

[sk_akbe]

@Olaf:
PS 219-Zeichen Dateiname klappt noch, ab 220 kommt die Fehlermeldung

Übel. Da weiß wohl die eine MS-Abteilung nicht (OS-Entwickler) was die andere (Backupprogramm-Programmierer) macht? Keine fest definierten Grenzwerte?

Die Frage ist jetzt, wo werden die 40 Zeichen "verbraucht"? Der Servername kann es in meinem Fall nicht sein, denn der hat nur 5 Zeichen.
Aber das Serverbackup läuft doch auf dem WHS? Dann müßte die Länge des Servernamens doch egal sein, da aus Sicht des Backup-Programmes alles lokale Dateien sind. Und die Serverbackup-Festplatte hängt ja auch direkt am WHS, sind also auch lokale Pfade.

Kann das mit dem Demigrator zusammenhängen? "Verschluckt/verbraucht" der vielleicht noch Zeichen? Die Shares liegen schließlich im Data-Pool und somit ausschließlich unter der Verwaltung des Demigrators?

[Nobby1805]

Kann das mit dem Demigrator zusammenhängen? "Verschluckt/verbraucht" der vielleicht noch Zeichen? Die Shares liegen schließlich im Data-Pool und somit ausschließlich unter der Verwaltung des Demigrators?

Glaube ich nicht ... wäre auch eigentlich nicht mehr "State of the art" so etwas im Namenspfad zu "verstecken"