7
Zu lange Pfade.....enstehen dadurch irgedwelche Schäden?
Hallo zusammen,
ich habe auf meinem Fileserver einige Dateien gefunden, die einen zu langen Pfad haben.
Nun musste ich auf die schnelle einige Zugriffberechtigungen ändern und bei dieser Änderung gab es halt die Fehlermeldung das die Syntax für die Datei fehlerhaft ist. Soweit sogut.....
Pfade gekürzt, User angemahnt.........
Nun meine Frage:
Weiß einer von Euch, ob durch die zu langen Pfade dauerhafte Schäden an dem Dateisystem enstehen oder ob das ganze durch die Kürzung (Löschung) erledigt ist ??
Vielen Dank im vorraus
ich habe auf meinem Fileserver einige Dateien gefunden, die einen zu langen Pfad haben.
Nun musste ich auf die schnelle einige Zugriffberechtigungen ändern und bei dieser Änderung gab es halt die Fehlermeldung das die Syntax für die Datei fehlerhaft ist. Soweit sogut.....
Pfade gekürzt, User angemahnt.........
Nun meine Frage:
Weiß einer von Euch, ob durch die zu langen Pfade dauerhafte Schäden an dem Dateisystem enstehen oder ob das ganze durch die Kürzung (Löschung) erledigt ist ??
Vielen Dank im vorraus
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 39152
Url: https://administrator.de/contentid/39152
Ausgedruckt am: 05.11.2024 um 16:11 Uhr
7 Kommentare
Neuester Kommentar
Moin Hannibal28,
Na ja, wenn Du möglichen Datenverlust als dauerhaften Schaden verstehst, dann: Ja.
Es kann halt (Danke an die M$-Qualitätssicherung!) passieren, dass Du eine Datei zwar anlegen/kopieren kannst in einen grenzwertig langen Pfad, aber hinterher nicht mehr dran kommst, weil exotischere Programme z.B. zum Rechte ändern, komprimieren, scannen...bla.. eine Pfadlängenbeschränkung implementiert haben, die um 1, 2 oder 10 zeichen kürzer ist.
Du kennst vielleicht ein ähnliches Problem vom CD-Brennen. Auch da kann es vorkommen, dass ein Teil einer komplexen Verzeichnisstruktur von Festplatte 1:1 kopiert auf der CD nicht lesbar ist.
Durch das Kürzen der Pfade ist aber das Problem behoben und die Gefahr gebannt.
Dauerhafte Risiken entstehen bestenfalls durch exotische Verzeichnis-Versteck-und-Verschlüssel-Tools angewendet auf "zu lange Pfade". Den Fall hatte ich schon, dass sich deren Implementierungsfehler im Verzeichnisbaum/in der MFT "fortpflanzen" und ganz andere Unterverzeichnisse unbrauchbar machen.
Gruß Biber
ob durch die zu langen Pfade dauerhafte Schäden an dem Dateisystem entstehen
Na ja, wenn Du möglichen Datenverlust als dauerhaften Schaden verstehst, dann: Ja.
Es kann halt (Danke an die M$-Qualitätssicherung!) passieren, dass Du eine Datei zwar anlegen/kopieren kannst in einen grenzwertig langen Pfad, aber hinterher nicht mehr dran kommst, weil exotischere Programme z.B. zum Rechte ändern, komprimieren, scannen...bla.. eine Pfadlängenbeschränkung implementiert haben, die um 1, 2 oder 10 zeichen kürzer ist.
Du kennst vielleicht ein ähnliches Problem vom CD-Brennen. Auch da kann es vorkommen, dass ein Teil einer komplexen Verzeichnisstruktur von Festplatte 1:1 kopiert auf der CD nicht lesbar ist.
Durch das Kürzen der Pfade ist aber das Problem behoben und die Gefahr gebannt.
Dauerhafte Risiken entstehen bestenfalls durch exotische Verzeichnis-Versteck-und-Verschlüssel-Tools angewendet auf "zu lange Pfade". Den Fall hatte ich schon, dass sich deren Implementierungsfehler im Verzeichnisbaum/in der MFT "fortpflanzen" und ganz andere Unterverzeichnisse unbrauchbar machen.
Gruß Biber
Hallo Biber,
erstmal Danke für die schnelle Antwort.
Den Datenverlust der paar Dateien kann ich ohne weiteres Verkraften.
Hatte nur Angst das die MFT oder ähnliches Schaden nimmt und andere Dateien in Mitleidenschaft zieht. Und leider sind wir ein 24/7 Betrieb und ich kann den Fileserver nicht mal einfach so auf Verdacht runterfahren und checkdisk durchlaufen lassen.
Schönen Dank
(P.S. Beschäftige mich grade bissl mit Batch und arbeite mich durch deine super Tuts oder um es anders zu sagen:
(Set Biber=RiesenvielenDankfürdiesegeilenTutorialsdiesupersindundmirRiesigweiterhelfen)
(Set Meinereiner=LangsamGroßerFanVonBatch
erstmal Danke für die schnelle Antwort.
Den Datenverlust der paar Dateien kann ich ohne weiteres Verkraften.
Hatte nur Angst das die MFT oder ähnliches Schaden nimmt und andere Dateien in Mitleidenschaft zieht. Und leider sind wir ein 24/7 Betrieb und ich kann den Fileserver nicht mal einfach so auf Verdacht runterfahren und checkdisk durchlaufen lassen.
Schönen Dank
(P.S. Beschäftige mich grade bissl mit Batch und arbeite mich durch deine super Tuts oder um es anders zu sagen:
(Set Biber=RiesenvielenDankfürdiesegeilenTutorialsdiesupersindundmirRiesigweiterhelfen)
(Set Meinereiner=LangsamGroßerFanVonBatch
Dauerhafte Schäden bei "normalen" Dateien sind mir auch noch nicht untergekommen.
Die einzigen Probleme bei meinen Anwendern mit ihren 10-20 Unterordnern waren, dass z.B. Acrobat oder Office Dateien zwar öffnen konnte, aber nicht mehr unter dem Pfad speichern.
Hat man nen anderen (kürzeren) Pfad eingestellt, konnte man Verlustfrei speichern.
Die einzigen Probleme bei meinen Anwendern mit ihren 10-20 Unterordnern waren, dass z.B. Acrobat oder Office Dateien zwar öffnen konnte, aber nicht mehr unter dem Pfad speichern.
Hat man nen anderen (kürzeren) Pfad eingestellt, konnte man Verlustfrei speichern.
Direkte Schäden entstehen nicht zwingend, indirekte sind fast unvermeidbar. Nur zwei Beispiele:
- Die meisten Backup Programme bekommen Schwierigkeiten mit überlangen Dateinamen. Teilweise werden diese einfach ignoriert.
- Viele andere Anwendungen haben für die Speicherung bzw. Benutzung von Dateinamen limitierte Feldgrößen. Damit können Überläufe und Fehler entstehen. MS-Office ist für solche Fehler berüchtigt.
Um dem Anwender aus diesem zweiten Dilemma vernünftig zu helfen kannst Du evtl. eine Subshare anlegen. Also statt \\server\share1\pfad2\pfad3\pfad4\datei eine extra share auf pfad4 dann lautet der Zugriff \\server\pfad4\datei und ist zumindest füpr die Applikationen des Anwenders kürzer geworden..
Unter Unix/Linux (reiser, ext2/3) hat ein überlanger Pfadname keine Auswirkung auf die Integrität des eigentlichen Dateisystems, da das Dateisystem über sogenannte inodes abgebildet wird. Für NTFS kann ich das nicht mit bestimmtheit sagen, FAT dürfte in jedem Fall irgendwann Probleme bekommen.
- Die meisten Backup Programme bekommen Schwierigkeiten mit überlangen Dateinamen. Teilweise werden diese einfach ignoriert.
- Viele andere Anwendungen haben für die Speicherung bzw. Benutzung von Dateinamen limitierte Feldgrößen. Damit können Überläufe und Fehler entstehen. MS-Office ist für solche Fehler berüchtigt.
Um dem Anwender aus diesem zweiten Dilemma vernünftig zu helfen kannst Du evtl. eine Subshare anlegen. Also statt \\server\share1\pfad2\pfad3\pfad4\datei eine extra share auf pfad4 dann lautet der Zugriff \\server\pfad4\datei und ist zumindest füpr die Applikationen des Anwenders kürzer geworden..
Unter Unix/Linux (reiser, ext2/3) hat ein überlanger Pfadname keine Auswirkung auf die Integrität des eigentlichen Dateisystems, da das Dateisystem über sogenannte inodes abgebildet wird. Für NTFS kann ich das nicht mit bestimmtheit sagen, FAT dürfte in jedem Fall irgendwann Probleme bekommen.
ich habe auf meinem Fileserver einige Dateien gefunden, die einen zu langen Pfad haben.
Soweit sogut..... Pfade gekürzt, User angemahnt.........
Soweit sogut..... Pfade gekürzt, User angemahnt.........
Der User kann unter Umständen nicht mal was dafür. Ich hatte das auch mal. Das kann beispielsweise entstehen, wenn Du auf dem Server eine recht komplexe Verzeichnisstruktur hast, die Freigabe aber recht weit hinten in dieser Struktur angesiedelt sind. Also z.B.
D:\Daten\im_Netz_freigegebene_Daten\firma\blabla\...\blubblubb\Einkauf\Schmidt\Angebotsvergleiche\lieferant1.xls
Freigegeben ist jetzt beispielsweise der Ordner D:\Daten\im_Netz_freigegebene_Daten\firma\blabla\...\blubblubb\Einkauf\Schmidt\ als \\fileserver\schmidt
Für Herrn Schmidt ist das dann \\fileserver\schmidt\Angebotsvergleiche\lieferant1.xls ... also ein definitiv nicht zu langer Pfad. Aber aus der Sicht des Servers betrachtet dann eben doch. Dafür kann dann aber der User nichts ...
Sorry wenn ich hier ein wenig philosophisch werde:
Solange das System nicht beim Anlegen schon meckert hat der User immer recht. Wenns dann Probleme gibt ist das Sache des Systemherstellers (in diesem Fall M$) solche Dinge zu verhindern oder hinterher keinen Mist damit zu machen.
Es reicht schon wenn Anwendungen die Hersteller API benutzen und auch noch die eigenen Anwendungen damit Schwierigkeiten haben.
Wenn sogar die MFT (also das Dateisystem selbst) durch Anlegen zu langer Pfade oder Dateinamen beschädigt werden kann dann ist doch irgendwas ziemlich krank ?
Dass ein FAT welches noch aus den 80ern stammt das nicht kann ist nachvollziehbar. Aber NTFS5 sollte doch solche Kinderkrankheiten überwunden haben. Ich denke es gibt ausreichend Entwickler bei M$ die das überprüft haben, oder vielleicht doch nicht, oder muss man erst noch Hotfix 0815-77 einspielen ??? Ach ja, Japanische Schriftzeichen (UTF-16) sind hoffentlich auch problemlos zu verarbeiten.
Mein gutgemeinter Rat: Wenn Systeme wirklich 24x7 betrieben werden sollen lasst die Finger von Windows oder leg zumindest deine Daten in SAN mit redundanten Servern und unabhängig gespiegelten Plattensystemen. Bei uns werden trotz ext3 regelmäßig halbjährlich Plattenchecks und Sichtprüfungen gefahren. So mancher wacklige Terminator oder ausgefallene Lüfter ist da schon aufgetaucht. Und dafür kann das Dateisystem wiederum gar nichts.
Solange das System nicht beim Anlegen schon meckert hat der User immer recht. Wenns dann Probleme gibt ist das Sache des Systemherstellers (in diesem Fall M$) solche Dinge zu verhindern oder hinterher keinen Mist damit zu machen.
Es reicht schon wenn Anwendungen die Hersteller API benutzen und auch noch die eigenen Anwendungen damit Schwierigkeiten haben.
Wenn sogar die MFT (also das Dateisystem selbst) durch Anlegen zu langer Pfade oder Dateinamen beschädigt werden kann dann ist doch irgendwas ziemlich krank ?
Dass ein FAT welches noch aus den 80ern stammt das nicht kann ist nachvollziehbar. Aber NTFS5 sollte doch solche Kinderkrankheiten überwunden haben. Ich denke es gibt ausreichend Entwickler bei M$ die das überprüft haben, oder vielleicht doch nicht, oder muss man erst noch Hotfix 0815-77 einspielen ??? Ach ja, Japanische Schriftzeichen (UTF-16) sind hoffentlich auch problemlos zu verarbeiten.
Mein gutgemeinter Rat: Wenn Systeme wirklich 24x7 betrieben werden sollen lasst die Finger von Windows oder leg zumindest deine Daten in SAN mit redundanten Servern und unabhängig gespiegelten Plattensystemen. Bei uns werden trotz ext3 regelmäßig halbjährlich Plattenchecks und Sichtprüfungen gefahren. So mancher wacklige Terminator oder ausgefallene Lüfter ist da schon aufgetaucht. Und dafür kann das Dateisystem wiederum gar nichts.
Hallo Ratzla,
Muss Dir in vielem Recht geben........................
Nur habe ich nich die Möglichkeit hier über Software oder ähnliches zu entscheiden.......
Wir bekommen hier was vor die Nase gesetzt und dann müssen wir sehen wie wir damit klar kommen.............
Achja und bei uns liegt es wirklich an den Usern......leider.
Die können so schöne Verzeichnissstrukturen anlegen...................
Muss Dir in vielem Recht geben........................
Nur habe ich nich die Möglichkeit hier über Software oder ähnliches zu entscheiden.......
Wir bekommen hier was vor die Nase gesetzt und dann müssen wir sehen wie wir damit klar kommen.............
Achja und bei uns liegt es wirklich an den Usern......leider.
Die können so schöne Verzeichnissstrukturen anlegen...................
