12
Kritische Pfadlänge für Benutzer kenntlich machen (Script)
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:
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.
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:
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:
set objFilesys = CreateObject("Scripting.FilesystemObject")
intArgsCount = wscript.arguments.count
if intArgsCount <> 4 then
wscript.echo "Falsche oder fehlende Argumente!" & vbCRLF & "Syntax: SetFolderWarnIcon <WARN-Länge> <ATTN-Länge> <EchoOn|EchoOff> <Basisverzeichnis>"
wscript.quit
end if
intFolderLenWarn = cint(wscript.arguments(0))
intFolderLenAttn = cint(wscript.arguments(1))
strListOn = wscript.arguments(2)
strSearchPath = wscript.arguments(3)
if right(strSearchPath,1) <> "\" then
strSearchPath = strSearchPath & "\"
end if
strDesktopIniOk = objFilesys.GetParentFoldername(wscript.ScriptFullname) & "\" & "desktop_ok.ini"
strDesktopIniWarn = objFilesys.GetParentFoldername(wscript.ScriptFullname) & "\" & "desktop_warn.ini"
strDesktopIniAttn = objFilesys.GetParentFoldername(wscript.ScriptFullname) & "\" & "desktop_attn.ini"
wscript.echo "Verzeichnislänge für Symbol WARN: " & intFolderLenWarn & vbcrlf & "Verzeichnislänge für Symbol ATTN: " & intFolderLenAttn & vbcrlf & "Basisverzeichnis: " & strSearchPath
'intFolderLenWarn = 50
'intFolderLenAttn = 80
ListFoldersInFolder strSearchPath
'wscript.echo "Fertig. Alle Verzeichnisse in " & strSearchPath & "geprüft und Icons eingerichtet."
Sub ListFoldersInFolder(strSearchPath)
on error resume next
set objFolderContent = objFilesys.GetFolder(strSearchPath)
for each strSubFolder in objFolderContent.Subfolders
'pfadlänge kürzer als WARN-Schwelle
if len(strSubFolder) < intFolderLenWarn then
if lcase(strListOn) = "echoon" then
wscript.echo "Ok: " & strSubFolder
end if
if strSubFolder.Attributes and 1 then
'+r für ordner schon gesetzt
objFilesys.CopyFile strDesktopIniOk, strSubFolder & "\desktop.ini"
else
'+r für ordner setzen
strSubFolder.Attributes = strSubFolder.Attributes + 1
objFilesys.CopyFile strDesktopIniOk, strSubFolder & "\desktop.ini"
end if
end if
'pfadlänge über WARN-Schwelle aber unter ATTN-Schwelle
if len(strSubFolder) => intFolderLenWarn and len(strSubFolder) <= intFolderLenAttn then
if lcase(strListOn) = "echoon" then
wscript.echo "Warn: " & strSubFolder
end if
if strSubFolder.Attributes and 1 then
'+r für ordner schon gesetzt
objFilesys.CopyFile strDesktopIniWarn, strSubFolder & "\desktop.ini"
else
'+r für ordner setzen
strSubFolder.Attributes = strSubFolder.Attributes + 1
objFilesys.CopyFile strDesktopIniWarn, strSubFolder & "\desktop.ini"
end if
end if
'pfadlänge über ATTN-Schwelle
if len(strSubFolder) > intFolderLenAttn then
if lcase(strListOn) = "echoon" then
wscript.echo "Attn: " & strSubFolder
end if
if strSubFolder.Attributes and 1 then
'+r für ordner schon gesetzt
objFilesys.CopyFile strDesktopIniAttn, strSubFolder & "\desktop.ini"
else
'+r für ordner setzen
strSubFolder.Attributes = strSubFolder.Attributes + 1
objFilesys.CopyFile strDesktopIniAttn, strSubFolder & "\desktop.ini"
end if
end if
ListFoldersInFolder strSubFolder
next
End SubEine desktop_ok.ini
[.ShellClassInfo]
IconResource=C:\Windows\system32\SHELL32.dll,45Eine desktop_warn.ini
[.ShellClassInfo]
IconResource=C:\Windows\system32\SHELL32.dll,147Eine desktop_attn.ini
[.ShellClassInfo]
IconResource=C:\Windows\system32\SHELL32.dll,234Die 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
cscript c:\pfadzumscript\setfolderwarnicon.vbs 170 200 EchoOn c:\daten\freigabe\Mit EchoOff geht auch der WScript als Standardinterpreter mit
setfolderwarnicon.vbs 170 200 EchoOff c:\daten\freigabe\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.
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: 231845
Url: https://administrator.de/contentid/231845
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
12 Kommentare
Neuester Kommentar
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
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
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...
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
.
Gruß
Evinben
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
.Gruß
Evinben
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.
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.
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.
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.
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.
Es ist eine gute Lösung für ein reales Problem.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
.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.
Zitat von @wiesi200:
Die sollten sich eher mal Gedanken machen das die Grenzen des Dateisystem auch vernünftig verwenden kann.
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
@manuel-r schön gemacht - thumps up
Gruß
@kontext
AFAIK haben dass die Jungs schon aus Redmond gemacht ...
... Stichwort ReFS - das kann ein paar Zeichen mehr als NTFS
... 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.
1Zitat 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.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.
Es geht sogar ganz ohne Volume/Junction, wenn man UNC Notation verwendet.
Gruss, Endoro.
Ich könnt mich jetzt echt täuschen, aber wenn man mit NortenCommander drauf zugreift hat man diese Probleme nicht.
Zitat von @wiesi200:
Ich könnt mich jetzt echt täuschen, aber wenn man mit NortenCommander drauf zugreift hat man diese Probleme nicht.
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ß
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
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
