Kritische Pfadlänge für Benutzer kenntlich machen (Script)

manuel-r
Goto Top
Wir alle kennen das Problem mit den zu langen Pfaden und allem was es an Problemen mit sich bringt.
Dummerweise hat MS es bis heute nicht geschafft das für den Benutzer brauchbar kenntlich zu machen und Fehlbedienung abzufangen.

Ich habe mich daher vor einiger Zeit mal dran gesetzt und ein kleines Script geschrieben. Nachdem dieses Script ein Verzeichnis und seine Unterverzeichnisse bearbeitet hat sieht das etwa so aus. Die gewählten Icons dürften ziemlich selbsterklärend sein:

1ed8494129c46cc9814f0e1e6b102b4d

Einen kleinen Haken hat das Script:
Die Pfadlänge die i.d.R. die Probleme verursacht ist die einschließlich des Dateinamens und Erweiterung. Da ich das Problem optisch lösen wollte konnte ich natürlich nicht die Icons der einzelnen Dateien manipulieren. Meine User würden mich umbringen, wenn ein PDF oder JPG plötzlich anders aussieht. Also habe ich bei mir die kritische Pfadlänge mit 200 Zeichen und die Länge aber der gewarnt wir mit 170 Zeichen gesetzt. Damit stehen dann bei einem Verzeichnis mit "rot" immer noch 50 Zeichen für Dateinamen zur Verfügung. Die Grenzwerte kann aber jeder halten wie er will.

Genug der Vorrede. Hier kommt das Script das einfach als "SetFolderWarnIcon.vbs" gespeichert wird:
Das Geheimnis des Scripts liegt in der Manipulation der desktop.ini jedes Ordners. Daher brauchen wir auch davon noch drei Vorlagen.

Eine desktop_ok.ini

Eine desktop_warn.ini

Eine desktop_attn.ini

Die drei INIs werden im gleichen Verzeichnis abgelegt wie das Script selbst.

Ausgeführt wird das Script in der Kommandozeile. Wenn eine fortlaufende Ausgabe der gerade abgearbeiteten Verzeichnisse gewünscht wird (Option: EchoOn) startet man das Script sinnvollerweise im CScript-Interpreter mit


Mit EchoOff geht auch der WScript als Standardinterpreter mit


Der erste Parameter (170) steht dabei für die untere Warnschwelle bei deren Überschreiten von "grün" auf "gelb" gewechselt wird. Der zweite Parameter (200) steht für die obere Warnschwelle. Oberhalb dieser Schwelle wird von "gelb" auf "rot" gewechselt. Der dritte Parameter (EchoOn) steht für eine Ausgabe der bearbeiteten Verzeichnisse. und zu guter letzt als vierter Parameter (d:\daten\freigabe\) das Verzeichnis da mitsamt Unterverzeichnissen bearbeitet werden soll.

Viel Spaß damit.

Content-Key: 231845

Url: https://administrator.de/contentid/231845

Ausgedruckt am: 03.07.2022 um 19:07 Uhr

Mitglied: evinben
evinben 06.03.2014 um 18:21:47 Uhr
Goto Top
fleißig gemacht!
Interessant wäre es nun dies als Dienst umzusetzen und laufen zulassen, sodass bei jeder Änderung im Pfad die Pfadlänge sofort geprüft wird.
Eigentlich wäre es für Microsoft kein Problem das Vorhaben im OS standardmäßig einzubauen. Wer weiß, vielleicht liest das einer und schlägt es denen vor.

Gruß
Evinben
Mitglied: manuel-r
manuel-r 06.03.2014 um 18:44:38 Uhr
Goto Top
Als Behelf tut es halt auch ein geplanter Task den man einmal täglich über die Shares am Fileserver laufen lässt. Je nach Anzahl der Verzeichnisse schafft man evtl auch mehrmals täglich. Geht halt auch ein bißchen auf die Ressourcen...
Mitglied: evinben
evinben 06.03.2014 aktualisiert um 20:22:43 Uhr
Goto Top
es müssen nicht nur freigegebene Ordner sein
Dein Einsatz ist generell für alle Pfade innerhalb von gesamtem Windows OS gut.
Wenn dies standardmäßig integriert wäre, würde es natürlich nur ein Bruchteil der Ressourcen verbrauchen.

Aber dein Script ist nicht nur eine bereits reale Lösung, sondern eine gute Anregung zur Umsetzung innerhalb des OS in Echtzeit - meine persönliche Prophezeiung face-wink.

Gruß
Evinben
Mitglied: Penny.Cilin
Penny.Cilin 07.03.2014 um 09:12:34 Uhr
Goto Top
Mein lieber Scholli, äääh manuel-r,

Da hast Du richtig gute Arbeit reingesteckt. Respekt, kann mich evinben nur anschliessen..

Ich werde es mal auf den Test Fileserver als Scheduled Task einrichten und zweimal am Tage laufen lassen. Mal schauen wie die Ressourcenbelastung ist.


Gruss Penny.
Mitglied: Endoro
Endoro 09.03.2014 um 14:23:05 Uhr
Goto Top
Hey,
ich finde nicht, dass das Problem dem user angelastet werden kann.
Der muss so was eigentlich nicht wissen.
Mit Links und Junctions können theoretisch endlose Pfade mit Bordmitteln entstehen.
Gruss, Endoro.
Mitglied: wiesi200
wiesi200 09.03.2014 um 21:05:18 Uhr
Goto Top
Zitat von @evinben:

Aber dein Script ist nicht nur eine bereits reale Lösung, sondern eine gute Anregung zur Umsetzung innerhalb des OS in
Echtzeit - meine persönliche Prophezeiung face-wink.

Es ist eine gute Lösung für ein reales Problem.
Innerhalb des OS also von Seiten MS wohl aber ein schlechter Ansatzpunkt. Die sollten sich eher mal Gedanken machen das die Grenzen des Dateisystem auch vernünftig verwenden kann.
Mitglied: kontext
kontext 10.03.2014 aktualisiert um 07:25:05 Uhr
Goto Top
Zitat von @wiesi200:
Die sollten sich eher mal Gedanken machen das die Grenzen des Dateisystem auch vernünftig verwenden kann.

Hallo @wiesi200,

AFAIK haben dass die Jungs schon aus Redmond gemacht ...
... Stichwort ReFS - das kann ein paar Zeichen mehr als NTFS face-wink

@manuel-r schön gemacht - thumps up face-smile

Gruß
@kontext
Mitglied: manuel-r
manuel-r 10.03.2014 um 07:57:36 Uhr
Goto Top
AFAIK haben dass die Jungs schon aus Redmond gemacht ...
... Stichwort ReFS - das kann ein paar Zeichen mehr als NTFS

Das Problem ist ja nicht die Anzahl der Zeichen die das verwendete Filesystem beherscht. Das Problem ist die Inkosistenz innerhalb des Betriebs-/Dateisystems:
Es ist problemlos möglich auf der 20. Ebene wo die Pfadlänge bspw. schon 240 Zeichen belegt noch Unterverzeichnis 21, 22, 23 und 24 anzulegen und dort dann auch noch Dateien abzulegen, damit man endgültig und ganz sicher über die Begrenzung kommt. Das kann jeder ausprobieren indem man bei Pfadlänge 240 ein ZIP entpackt, das selbst eine längere Verzeichnisstruktur beinhaltet: Das OS packt die gnadenlos aus und legt Verzeichnisse und Dateien an. Problematisch wird es wenn bspw. die Datensicherung vorbei kommt um dort was zur Sicherung abzuholen oder der User aus diesem Ordner nochmal was löschen oder verschieben will. Das wird dann vom OS mit Lesefehler quittiert.
Die einzige Lösung wieder auf die Dateien zuzugreifen liegt dann in einem net use oder subst auf einen Pfad der weit genug in der Hierarchie drin ist.
Wenn das OS es richtig machen wollte, dann würde es beim Anlegen von Verzeichnissen bzw. Dateien die Pfadlänge prüfen und dem User entsprechend Bescheid geben in der Form "Die Länge von Pfad und/oder Dateiname überschreitet die Anzahl der maximal möglichen Zeichen. Bitte wählen Sie einen anderen Namen." Das wäre für den Benutzer handelbar.
Mitglied: Endoro
Endoro 10.03.2014 um 08:54:24 Uhr
Goto Top
Zitat von @manuel-r:
Die einzige Lösung wieder auf die Dateien zuzugreifen liegt dann in einem net use oder subst auf einen Pfad der weit
genug in der Hierarchie drin ist.
Wie schon gesagt, eine Junction in die Hirarchie genügt. Man benötigt kein neues Volume.
Es geht sogar ganz ohne Volume/Junction, wenn man UNC Notation verwendet.
Gruss, Endoro.
Mitglied: wiesi200
wiesi200 10.03.2014 um 08:57:43 Uhr
Goto Top
Zitat von @kontext:

> Zitat von @wiesi200:
> Die sollten sich eher mal Gedanken machen das die Grenzen des Dateisystem auch vernünftig verwenden kann.

Hallo @wiesi200,

AFAIK haben dass die Jungs schon aus Redmond gemacht ...
... Stichwort ReFS - das kann ein paar Zeichen mehr als NTFS face-wink

Ich könnt mich jetzt echt täuschen, aber wenn man mit NortenCommander drauf zugreift hat man diese Probleme nicht.
Mitglied: kontext
kontext 10.03.2014 aktualisiert um 09:06:44 Uhr
Goto Top
Zitat von @wiesi200:
Ich könnt mich jetzt echt täuschen, aber wenn man mit NortenCommander drauf zugreift hat man diese Probleme nicht.

Kann gut möglich sein, denn:
NTFS unterstützt glaub irgendwas um die 32000 Zeichen wenn diese nicht im Unicode vorliegen.
Der Win-Explorer verwendet Unicode und da sind es nur 255 Zeichen.
ReFS kann jetzt 32768 Zeichen in UniCode. Also sollte der Explorer & Co kein Problem damit haben ...

Gruß
Mitglied: evinben
evinben 10.03.2014 aktualisiert um 09:23:16 Uhr
Goto Top
dem manuel-r@ stimme ich völlig zu. Genau diese Probleme treten in der Praxis auf. Es sind zwar noch kleine Probleme, aber sie sind völlig ausreichend, um den gesamten Diskomfort über die Jahre von OS zu OS unbemerkt mitzuschleppen.
Den Anwendern blieb ja nichts anderes übrig, als diese Beschränkung so anzunehmen wie sie ist und weil es eben eine „Kleinigkeit“ ist, dass alleine nur aus diesem Grund kaum einer mehr auf diese Problematik schaut und somit die Akzeptanz geschaffen war.
Das ist so wie mit den quietschenden Türen: es fängt allmählich leise zu quietschen an, alle gewöhnen sich daran, bis es dann jemandem nach Monaten oder sogar Jahren so dermaßen auffällt und er sie alle ordentlich schmiert oder sogar gelagert umkonstruiert. Paradox ist es dann, dass es überraschenderweise dennoch Leute gibt, welche das „Guqietsche“ vermissen und welche die sich sogar wundern, was da nicht in Ordnung wäre und warum etwas geändert werden muss, wenn es funktioniert.

Gruß
Evinben